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Abstract 


The  Software  Engineering  Institute  is  undertaking  a  feasibility  study  of  “component-based 
software  engineering”  (CBSE).  The  objective  of  this  study  is  to  determine  whether  CBSE 
has  the  potential  to  advance  the  state  of  software  engineering  practice  and,  if  so,  whether  the 
SEI  can  contribute  to  this  advancement.  This  report  is  the  second  part  of  a  three-part  report 
on  the  study.  Volume  I  contains  a  market  assessment  for  CBSE.  Volume  III  outlines  a  pro¬ 
posed  course  of  action  for  the  SEI.  Volume  II,  this  report,  establishes  the  technical  founda¬ 
tion  for  SEI  work  in  CBSE.  The  paper  asserts  that  the  key  technical  challenge  facing  CBSE 
is  to  ensure  that  the  properties  of  a  system  of  components  can  be  predicted  from  the  proper¬ 
ties  of  the  components  themselves.  The  key  technical  concepts  of  CBSE  that  are  needed  to 
support  this  vision  are  described:  component,  interface,  contract,  component  model,  compo¬ 
nent  framework,  composition,  and  certification. 
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1  Nothing  New  Under  the  Sun? 


The  whole  comprises  its  parts,  and  the  parts  compose  the  whole.  To  compose,  from  the  Latin 
cum  “together”  and  ponere  “to  put.”  The  parts  that  we  compose  are,  etymologically  speak¬ 
ing,  components.  Why  this  pedagogy?  Because,  by  definition,  all  software  systems  comprise 
components.  These  components  result  from  problem  decomposition,  a  standard  problem¬ 
solving  technique.  In  the  software  world,  different  conceptions  about  how  systems  should  be 
organized  result  in  different  kinds  of  components.  Thus,  two  systems  may  comprise  compo¬ 
nents,  but  the  components  may  have  nothing  more  in  common  than  the  name  “component.” 
The  phrase  component-based  system  has  about  as  much  inherent  meaning  as  “part-based 
whole.” 

This  is  not  to  suggest  that  software  component  technology  has  not  emerged  in  recent  years  as 
a  significant  factor  in  how  systems  are  built.  Indeed,  as  indicated  in  a  companion  volume  to 
this  report,  “The  Component-Based  Software  Engineering  (CBSE)  Market  Assessment,” 
software  component  technology  is  thriving  and  most  analysts  predict  continued  growth  over 
the  next  5-10  years.  Unfortunately,  these  predictions  are  tainted  by  a  lack  of  agreement 
among  analysts  about  what  software  components  are,  and  how  they  are  used  to  design,  de¬ 
velop  and  field  new  systems.  This  lack  of  agreement  among  analysts  extends  also  to  re¬ 
searchers,  technology  producers,  and  consumers.  But  this  diversity  is  to  be  expected  in  a  new 
technology,  and  we  should  be  careful  not  exaggerate  the  extent  of  this  diversity:  although 
there  are  differences  they  are  often  quite  subtle.  By  and  large,  there  is  general  agreement  on 
the  broad  outlines  of  what  constitutes  software  component  technology,  and,  by  extension, 
component-based  systems. 

It  is  the  task  of  this  report  to  sharpen  these  broad  outlines  into  a  more  coherent  and  detailed 
picture  of  software  component  technology  by  exposing  its  constituent  components:  technical 
concepts.  Our  objective  is  not  to  develop  ironclad  definitions  of  these  concepts  (a  futile  ex¬ 
ercise),  but  rather  to  highlight  what  is  most  significant.  To  know  what  is  most  significant, 
however,  requires  an  understanding  of  how  software  component  technology  is  used  or,  more 
to  the  point,  how  this  technology  should  be  used  in  the  service  of  an  overall  engineering  dis¬ 
cipline  based  in  software  components.  Not  surprisingly,  we  call  this  engineering  discipline 
component-based  software  engineering  (CBSE).  Thus,  it  is  also  the  task  of  this  report  to  ar¬ 
ticulate  a  vision  for  CBSE  that  we  can  use  to  orient  the  discussion  of  technical  concepts. 

In  Section  2  we  begin  with  a  reference  model  of  software  component  technology  that  identi¬ 
fies  and  relates  most,  but  not  all,  of  the  technical  concepts  underlying  software  component 
technology.  This,  we  believe,  will  give  the  reader  the  gestalt  of  software  component  technol- 
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ogy  that  will  serve  as  a  touchstone  for  the  more  detailed  discussions  that  follow.  We  then  pre¬ 
sent  in  Section  3  a  vision  statement  for  CBSE  that  provides  a  context  in  which  the  technical 
concepts  can  be  elaborated.  Sections  4  through  9  examine  the  technical  concepts  of  software 
component  technology  that  support  the  engineering  vision:  components ,  interfaces ,  contracts, 
component  models  and  frameworks,  composition,  and  certification.  While  none  of  these  con¬ 
cepts  is  entirely  new,  their  relation  to  each  other  and  to  other  technical  concepts  such  as  soft¬ 
ware  architecture  marks  this  technology  as  something  new.  Finally,  in  Section  10  we  summa¬ 
rize  the  key  points  and  build  a  bridge  to  Volume  III. 


2 


CMU/SEI-2000-TR-008 


2  Software  Component  Technology 


Component-based  systems  result  from  adopting  a  component-based  design  strategy,  and 
software  component  technology  includes  the  products  and  concepts  that  support  this  design 
strategy.  By  design  strategy  we  mean  something  very  close  to  architectural  style — a  high- 
level  design  pattern  described  by  the  types  of  components  in  a  system  and  their  patterns  of 
interaction  [Bass  98],  Software  component  technology  reflects  this  design  pattern,  which  is 
depicted  graphically  in  Figure  1.  This  reflection  is  due  to  the  fact  that  software  component 
technology  does  not  exist  only  in  development  tools  but  also  becomes  part  of  the  deployed 
application  or  system.  This  pattern  is  found  in  commercial  software  component  technologies 
such  as  Sun  Microsystems’  Enterprise  JavaBeans™  and  Microsoft’s  COM+,  as  well  as  in 
research  prototypes  such  as  the  SEI  WaterBeans  [Plakosh  99]  and  many  others.  A  high-level 
understanding  of  this  design  pattern  is  instrumental  to  later,  more  detailed  discussions. 


(D  Implements  interface 
and  satisfies  contract 


Figure  1:  The  Component-Based  Design  Pattern 


A  component  (©)  is  a  software  implementation  that  can  be  executed  on  a  physical  or  logical 
device.  A  component  implements  one  or  more  interfaces  that  are  imposed  upon  it  (@).This 
reflects  that  the  component  satisfies  certain  obligations,  which  we  will  later  describe  as  a 
contract  (®).  These  contractual  obligations  ensure  that  independently  developed  components 
obey  certain  rules  so  that  components  interact  (or  can  not  interact)  in  predictable  ways,  and 
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can  be  deployed  into  standard  build-time  and  run-time  environments  (©).  A  component- 
based  system  is  based  upon  a  small  number  of  distinct  component  types,  each  of  which  plays 
a  specialized  role  in  a  system  (©)  and  is  described  by  an  interface  (©).  A  component  model 
(©)  is  the  set  of  component  types,  their  interfaces,  and,  additionally,  a  specification  of  the 
allowable  patterns  of  interaction  among  component  types.  A  component  framework  (®)  pro¬ 
vides  a  variety  of  runtime  services  (©)  to  support  and  enforce  the  component  model.  In 
many  respects  component  frameworks  are  like  special-purpose  operating  systems,  although 
they  operate  at  much  higher  levels  of  abstraction. 

Figure  1  is  a  reference  model  for  component-based  concepts.  But,  as  with  all  reference  mod¬ 
els,  there  is  a  danger  of  reading  too  much  into  the  picture.  For  example,  Week  equates  com¬ 
ponent  model  and  frameworks,  and  suggests  that  the  framework  may  or  may  not  include 
services  [Week  96].  Microsoft’s  COM+,  on  the  other  hand,  embeds  the  component  frame¬ 
work  into  the  operating  system  itself  obviating  the  need  for  a  separate  entity  called  “compo¬ 
nent  framework”  [Box  98],  Indeed,  it  is  difficult  to  find  categorical  distinctions  between 
component  frameworks  and  operating  systems,  as  both  provide  coordination  mechanisms  that 
enforce  a  particular  model  of  component  interactions.  Nevertheless,  we  assert  there  are 
qualitative  distinctions;  for  example,  component  frameworks  will  support  a  more  restricted 
range  of  coordination  schemes  than  a  general-purpose  operating  system. 

Figure  1  depicts  the  design  pattern,  but  what  is  it  that  motivates  this  pattern  in  the  first  place? 
The  following  appear  to  be  the  most  significant  factors: 

•  Independent  extensions.  One  problem  that  plagues  legacy  software  is  lack  of  flexibil¬ 
ity.1  Components  are  units  of  extension,  and  a  component  model  prescribes  exactly  how 
extensions  are  made.  In  some  cases  the  framework  itself  may  constitute  the  running  ap¬ 
plication  into  which  extensions  (components)  are  deployed.  The  component  model  and 
framework  ensure  that  extensions  do  not  have  unexpected  interactions,  thus  extensions 
(components)  may  be  independently  developed  and  deployed. 

•  Component  markets.  Component  models  prescribe  the  necessary  standards  to  ensure 
that  independently  developed  components  can  be  deployed  into  a  common  environment, 
and  will  not  experience  unanticipated  interactions  such  as  resource  contention.  The  inte¬ 
gration  of  support  services  in  a  framework  also  simplifies  the  construction  of  compo¬ 
nents,  and  provides  a  platform  upon  which  families  of  components  can  be  designed  for 
particular  application  niches.  The  Theory  Center  case  study  discussed  in  the  companion 
Volume  I  Market  Assessment  illustrates  a  component-based  product  line. 

•  Reduced  time-to-market.  The  availability  of  components  of  the  sort  just  described  also 
promises  to  drastically  reduce  the  time  it  takes  to  design,  develop  and  field  systems.  De¬ 
sign  time  is  drastically  reduced  because  key  architectural  decisions  have  been  made  and 
are  embodied  in  the  component  model  and  framework.  Component  families  such  as 
those  found  in  the  Theory  Center  obviously  contribute  to  reduced  time  to  market.  Even  if 
such  component  families  are  not  available  in  an  application  domain  the  uniform  compo¬ 
nent  abstractions  will  reduce  development  and  maintenance  costs  overall. 

1  One  definition  of  “legacy”  precisely  describes  it  as  a  system  which  is  no  longer  sufficiently  flexible 
to  be  adapted  in  a  cost-effective  way. 
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•  Improved  predictability.  Component  models  and  frameworks  can  be  designed  to  sup¬ 
port  those  quality  attributes  that  are  most  important  in  particular  application  areas.  Com¬ 
ponent  models  express  design  mles  that  are  uniformly  enforced  over  all  components  de¬ 
ployed  in  a  component-based  system.  This  uniformity  means  that  various  global 
properties  can  be  “designed  into”  the  component  model  so  that  properties  such  as  seal- 
ability,  security  and  so  forth  can  be  predicted  for  the  system  as  a  whole.  For  example, 
EJB™  is  touted  as  promising  scalable,  secure,  and  distributed  transactions  by  virtue  of  its 
component  model  and  framework  services. 

It  might  be  argued  that  there  are  other  benefits  that  accrue  from  a  component-based  approach 
to  systems  (as  that  approach  is  discussed  here).  However,  the  benefits  described  here  are  suf¬ 
ficient  to  motivate  the  following  discussion.  More  details  on  market  perceptions  concerning 
the  benefits  of  component-based  software  can  be  found  in  Volume  I  of  this  report. 

Summary  of  Key  Points 

Software  component  technology  supports  building  a  particular  style  that  includes  compo¬ 
nents,  component  models,  and  component  frameworks.  The  component  model  imposes  de¬ 
sign  constraints  on  component  developers,  and  the  component  framework  enforces  these  con¬ 
straints  in  addition  to  providing  useful  services. 
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3  Vision  Statement 


As  one  modem  adage  has  it,  “point  of  view  is  worth  twenty  IQ  points.”2  Having  a  point  of 
view  means  having  a  vision  of  how  things  are,  so  that  what  is  important  can  be  sorted  from 
what  is  unimportant,  and  so  that  the  tendency  of  things  can  be  understood  and  hence  pre¬ 
dicted.  It  is  for  this  reason  that  we  express  a  vision  statement  for  CBSE.  Through  it  we  hope 
to  obtain  all  of  these  benefits  (IQ,  perhaps,  excluded). 

We  must  decide  between  a  broad  or  narrow  vision.  A  broad  vision  will  include  things  such  as 
organizational  models,  business  models,  life-cycle  models  and  processes,  engineering  roles, 
skills,  enabling  technologies,  and  so  forth.  A  narrow  vision  will  articulate  some  aspect  of 
CBSE  that  is  a  lynchpin  for  a  broader  vision.  The  virtue  of  a  broad  vision  is  its  inclusiveness, 
while  its  weakness  can  be  lack  of  focus;  a  narrow  vision  of  course  has  complementary 
strengths  and  weaknesses. 

We  have  elected  to  pursue  a  narrow  vision  of  CBSE.  The  vision  we  describe  is  focused  on 
the  most  fundamental  aspect  of  CBSE-predictable  composition-without  which  CBSE  lacks 
meaning  independent  from  already  established  thrusts  in  software  engineering  practice,  for 
example  software  architecture  or  use  of  commercial  off-the-shelf  (COTS)  software.  We  do 
not  claim  that  this  vision  is  novel  or  unique  to  the  SEI.  We  do  claim,  however,  that  it  ex¬ 
presses  the  nub  of  what  engineering  means  in  any  meaningful  CBSE  practice. 

Component-based  software  engineering  is  concerned  with  the 
rapid  assembly  of  systems  from  components  where 

•  components  and  frameworks  have  certified  properties;  and 

•  these  certified  properties  provide  the  basis  for  predicting 
the  properties  of  systems  built  from  components 

The  above  statement  is  minimal  but  aggressive.  The  gist  of  the  vision  is  expressed  in  the 
three  underlined  stipulations,  taken  out  of  order  for  expository  reasons: 

•  Predicting  the  property  of  a  solution  from  its  constituent  parts  is  fundamental  to  all  ma¬ 
ture  engineering  disciplines.  The  desire  to  achieve  this  result  for  software  systems  has 
motivated  much  research  in  software  engineering  science,  for  example  work  in  so-called 
“formal  methods”  and  software  architecture.  This  stipulation  can  be  viewed  as  either  the 
“Holy  Grail”  or  sine  qua  non  to  a  software  engineering  discipline  based  on  components. 


2  Attributed  to  Adele  Goldberg. 
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These  views  are  not,  incidentally,  mutually  exclusive,  since  there  is  a  limit  on  the  scope 
and  accuracy  of  system  predictions  in  even  the  most  mature  engineering  disciplines. 

•  It  is  highly  improbable  that  an  engineer  could  predict  the  property  of  a  system  without 
having  the  benefit  of  knowing  the  properties  of  the  parts  that  comprise  the  system.  Certi¬ 
fication  of  component  and  framework  properties  is  important  because  it  implies  that  en¬ 
gineers  will  be  working  with  software  products  that  are  (or  have)  “known  quantities.”  It 
also  implies  (but  possibly  does  not  mandate)  an  authoritative  industrial  approach  to  ob¬ 
taining  trust  in  the  properties  of  the  fundamental  building  blocks  of  software  systems. 

•  Rapid  assembly  is  important  because,  as  noted  in  the  Market  Assessment,  reduced  time 
to  market  is  a  primary  motivation  for  adopting  software  component  technology.  It  will 
little  avail  us  to  find  a  way  of  satisfying  the  previous  two  stipulations  if  doing  so  requires 
substantially  more  development  time  than  is  already  the  case.  Indeed,  it  can  be  argued 
that  prediction  and  certification  is  important  precisely  because  they  support  the  ultimate 
objective  of  reducing  the  time  it  takes  to  design  and  build  software  systems. 

In  the  interest  of  concision  many  nuances  have  been  omitted  from  the  vision  statement.  For 
example,  predicting  system  properties  requires  that  the  properties  of  the  interactions  among 
components  and  between  components  and  framework  must  also  be  known  in  addition  to  the 
properties  of  components  and  frameworks.  There  is  also  a  strong  connection  between  the 
vision  statement  and  commercial  markets  in  components,  frameworks,  and  certification.  The 
commercial  technology  market  is  driving  advances  in  software  component  technology,  and  a 
failure  to  accommodate  these  market  realities  in  CBSE  would  be  a  decisive  error. 

Summary  of  Key  Points 

A  vision  of  an  ideal  CBSE  practice  is  essential  if  we  are  to  understand  software  component 
technology  and  the  ways  in  which  this  technology  supports  or  hinders  sound  software  engi¬ 
neering  practice.  The  SEI  vision  for  CBSE  emphasizes  rapid  assembly  of  certified  compo¬ 
nents  and  frameworks  into  systems  whose  properties  can  be  predicted  beforehand. 
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4  Components 


There  is  no  shortage  of  definitions  of  component  in  the  literature.  This  is  not  surprising,  as 
different  understandings  of  problems  to  be  solved  and  approaches  to  solving  these  problems 
invariably  lead  to  different  understandings  of  the  constituent  parts  (components)  of  solutions 
to  problems.  Advocates  of  software  reuse  equate  components  to  anything  that  can  be  reused; 
practitioners  using  commercial  off-the-shelf  (COTS)  software  equate  components  to  COTS 
products;  software  methodologists  equate  components  with  units  of  project  and  configuration 
management;  and  software  architects  equate  components  with  design  abstractions.  There  are 
other  analogous  equations  throughout  the  literature. 

Even  within  the  self-described  component-based  software  engineering  community  there  is 
considerable  variation  in  definitions  of  component,  although  these  variations  are  usually  quite 
subtle.  The  SEI  definition  is  consistent  with  the  overall  thrust  of  these  definitions,  notably 
Szyperski’s  [Szyperski  98].  But  the  SEI  approach  to  components  strongly  reflects  an  argu¬ 
ment  made  by  Wang  that  software  components  merge  two  distinct  perspectives:  component 
as  implementation  and  component  as  architectural  abstraction  [Wang  99].  We  will  tempo¬ 
rarily  denote  this  union  as  an  architectural  component;  we  will  later  dispense  with  the  adjec¬ 
tive  architectural  as  being  implied  by  the  definition. 

The  concept  of  component  as  implementation  is  a  familiar  one  found  in  the  marketplace,  and 
as  mentioned  above  is  most  often  used  to  refer  to  COTS  products.  But  COTS  products  may 
implement  functionality  (what  a  component  does)  and  coordination  (how  a  component  inter¬ 
acts  with  the  external  world)  in  a  way  that  is  unique  to  the  product.  In  contrast,  architectural 
components  are  required  to  implement  one  or  more  interfaces  that  prescribe  how  components 
may  interact  or  other  architectural  constraints.  In  Section  2  we  stated  that  these  interfaces  are 
constituent  parts  of  a  component  model.  It  is  compliance  with  a  component  model  that 
makes  a  component  architectural.  This  leads  to  the  following  definition  of  software  compo¬ 
nent. 


A  Component  is: 

•  on  opaque  implementation  of  functionality 

•  subject  to  third-party  composition 

•  conformant  with  a  component  model 


There  are  two  motivations  for  the  criterion  that  a  component  is  an  opaque  implementation. 
First,  we  envision  a  commercial  market  in  software  components.  Notwithstanding  the  suc- 
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cess  of  Linux  and  “open  source”  software,  the  predominant  and  most  successful  business 
model  for  software  components  has  been  based  upon  software  as  intellectual  capital  that  must 
be  protected  from  disclosure.  This  is  likely  to  remain  true  for  the  foreseeable  future,  and  a 
technical  agenda  for  CBSE  must  assume  therefore  that  components  will  remain  “black 
boxes”  to  consumers.  Second,  as  is  already  a  well-established  precept  in  computer  science, 
clients  of  software  components  should  not  come  to  rely  upon  implementation  details  that  are 
likely  to  change.  In  computer  science  this  has  led  to  programming  support  for  abstraction 
and  information  hiding;  opaqueness  serves  the  same  purpose  for  components. 

The  motivation  for  third-party  composition  is  straightforward:  the  use  of  components  should 
not  depend  upon  tools  or  knowledge  of  the  component  that  is  in  the  possession  of  only  the 
component  provider.  This  criterion  implies  that  a  component-based  system  can  comprise 
components  from  multiple,  independent  sources,  and  that  a  system  can  be  assembled  by  a 
third  party  system  integrator  who  is  not  also  a  component  supplier.  This  criterion  should  hold 
true  even  if  none  of  the  components  used  in  a  system  come  from  external  suppliers. 

The  last  criterion,  that  a  component  is  conformant  with  a  component  model,  is  what  differen¬ 
tiates  components  from  conventional  COTS  software  products.  Component  models  prescribe 
how  components  interact  with  each  other,  and  therefore  express  global,  or  architectural  de¬ 
sign  constraints.  Conformance  to  component  models  transforms  software  implementations 
into  architectural  implementations.  In  contrast  to  COTS-based  systems,  which  result  in  a 
hodge-podge  integration  of  product-specific  interaction  schemes,  component-based  systems 
are  based  in  uniform,  standard  coordination  schemes. 

As  with  the  CBSE  Vision,  all  three  criteria  reflect  the  background  forces  of  a  commercial 
market  in  software  component  technology. 

Summary  of  Key  Points 

A  software  component  merges  two  distinct  perspectives:  component  as  an  implementation 
and  component  as  an  architectural  abstraction;  components  are  therefore  architectural  imple¬ 
mentations.  Viewed  as  implementations,  components  can  be  deployed,  and  assembled  into 
larger  (sub)systems.  Viewed  as  architectural  abstractions,  components  express  design  rules 
that  impose  a  standard  coordination  model  on  all  components.  These  design  rules  take  the 
form  of  a  component  model,  or  a  set  of  standards  and  conventions  to  which  components  must 
conform. 
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5  Interfaces 


Our  ability  to  integrate  components  into  assemblies,  to  reason  about  these  assemblies,  and  to 
develop  a  market  of  components  depends  fundamentally  on  the  notion  of  component  inter¬ 
face.  The  concept  of  interface  is  basic  and  familiar.  But  familiarity  sometimes  breeds  con¬ 
tempt,  and  the  concept  of  interface  is  more  complex  than  is  often  appreciated.  Moreover,  the 
criticality  of  interfaces  to  CBSE  exposes  limitations  in  conventional  approaches  to  interface 
specification. 

5.1  Interface  Abstraction  and  Application 
Programming  Interfaces 

Interface  abstraction  provides  a  mechanism  to  control  the  dependencies  that  arise  between 
modules3  in  a  program  or  system.  An  application  programming  interface  (API)  is  a  specifi¬ 
cation,  in  a  programming  language,  of  those  properties  of  a  module  that  clients  of  that  mod¬ 
ule  can  depend  upon.  Conversely,  clients  should  not  depend  upon  properties  that  are  not 
specified  by  the  API.  All  modem  programming  languages  support  some  form  of  interface 
abstraction,  e.g.,  Smalltalk-80,  C++,  Modula-3,  Ada-98,  Java  and  ML.  Some  language- 
neutral  interface  specification  languages  have  been  developed  such  as  the  Object  Manage¬ 
ment  Group’s  (OMG)  Interface  Definition  Language  (DDL). 

Design  and  implementation  decisions  that  are  unlikely  to  change  are  specified  in  the  API, 
while  decisions  that  are  likely  to  change  are  “hidden”  from  clients.  The  theory  is  that  infor¬ 
mation  hiding  makes  modules  substitutable  (for  example,  with  new  versions  of  a  component), 
and  hence  makes  systems  easier  to  change,  at  least  insofar  as  module  substitution  is  con¬ 
cerned.  This  turns  out  to  be  a  weak  theory,  however,  as  it  depends  upon  API's  being  silent 
about  properties  that  clients  should  not  depend  upon.  But  the  API  can  only  be  silent  about 
properties  about  which  it  can  speak,  and  programming  languages  are  only  equipped  to  speak 
about  a  narrow  range  of  properties.  All  other  properties  can  “leak”  through  the  interface  ab¬ 
straction. 

Conventional  APIs — that  is,  interface  specifications  written  in  programming  languages  such 
as  those  cited  above — can  conveniently  express  what  we  will  refer  to  as  functional  properties. 
Functional  properties  include  the  services  a  module  provides  and  the  signature  of  these  serv¬ 
ices — the  types  and  order  of  arguments  to  the  service  and  the  manner  in  which  results  are 
returned  from  the  service.  Conventional  APIs  are  not  so  well  equipped  to  express  what  we 


3  We  will  use  the  term  module  to  refer  to  software  implementations  that  have  interfaces;  we  reserve  the 
use  of  the  term  component  to  things  that  satisfy  the  SEI  definition  of  that  term. 
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refer  to  as  extra-functional  properties.  These  properties  include  things  like  performance,  ac¬ 
curacy,  availability,  latency,  security,  and  so  forth.  These  are  often  referred  to  as  quality  at¬ 
tributes,  or,  when  associated  with  a  particular  service,  quality  of  service.  Because  APIs  can 
not  describe  these  properties,  they  can  not  hide  them.  Indeed,  modules  may  come  to  depend 
upon  any  of  these  properties,  thus  reducing  the  probability  that  one  module  can  be  substituted 
for  another. 

Note  that  just  because  an  extra-functional  property  is  not  expressed  in  an  API  does  not  a  pri¬ 
ori  mean  that  this  property  will  be  the  source  of  a  dependency — it  will  only  become  a  de¬ 
pendency  if  a  client  relies  upon  this  property.  This  is  cold  comfort,  however,  since  many 
more  such  dependencies  arise  than  is  usually  recognized  by  programmers  and  designers. 

5.2  Extending  APIs  to  Extra-Functional  Properties 

Attempts  have  been  made  to  extend  APIs  to  make  them  more  expressive  of  extra-functional 
properties.  These  extensions  are  motivated  more  by  the  desire  to  ensure  that  interface  speci¬ 
fications  are  sufficiently  complete  to  ensure  correct  integration  than  by  the  desire  to  extend 
the  scope  of  information  hiding  to  additional  properties.  Both  ends  are  served  by  these  ex¬ 
tensions,  however. 

For  the  following  discussion  it  will  be  useful  to  differentiate  the  various  kinds  of  extra¬ 
functional  properties  that  have  been  the  subject  of  attempts  to  extend  APIs.  Beugnard  et.  al. 
define  four  kinds  of  property:  syntactic,  behavioral,  synchronization,  and  quality  of  service 
[Beugnard  99].  Although  no  classification  scheme  is  perfect,  this  one  will  do  for  our  pur¬ 
poses.  Syntactic  properties  correspond  to  functional  properties  as  we  have  just  described 
them.  The  other  properties  are  extra-functional,  and  the  means  of  expressing  these  are  now 
discussed.  Many  of  the  topics  discussed  below  were  explored  in  depth  at  a  workshop  on  the 
Foundations  of  Component-Based  Systems  held  in  Zurich,  Switzerland  in  September  1997 
[Leavens  97]. 

5.2.1  Specifying  Behavior 

Beugnard  et.  al.  suggest  that  behavioral  specifications  define  the  outcome  of  operations 
[Beugnard  99].  Programming  languages  such  as  Eiffel  [Meyer  97]  and  SPARK  [Barnes  97] 
allow  for  behavioral  specifications  to  be  written  into  the  program  code  using  pre-  and  post¬ 
conditions  and  other  forms  of  assertions.  Neither  of  these  languages  is  widely  used  and  this 
technique  is  not  available  in  the  more  commonly  used  languages.  However,  there  are  at  least 
five  recent  attempts  to  extend  the  Java  programming  language  in  this  way:  iContract  [Kramer 
98],  JML  (Java  Modeling  Language)  [Leavens  99],  Jass  (Java  with  assertions)  [Fischer  99], 
Biscotti  [Della  99],  and  JINSLA  (Java  INterface  Specification  LAnguage)  [Mikhajlova  99]. 
This  diversity  illustrates  the  fact  that  such  approaches  are  still  not  mainstream  and  that  the 
industry  has  not  yet  picked  a  single  winner  in  this  area. 
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Formal  methods  such  as  VDM,  Z  or  Larch  may  also  be  used  to  specify  the  behavior  of  soft¬ 
ware  components  [Goldsack  97,  Johnson  97,  Ciancarani  97].  These  methods  are  becoming 
more  widely  used  but  they  are  still  not  regarded  as  mainstream.  These  well-established  for¬ 
mal  methods  were  introduced  before  the  advent  of  object-oriented  programming.  However, 
they  can  still  be  used  in  the  specification  of  object-oriented  systems,  even  though  they,  them¬ 
selves,  do  not  directly  support  object  orientation.  More  recently,  object-oriented  extensions 
of  these  traditional  methods  have  been  developed;  e.g.,  OOZE  [Alencar  92],  VDM++  [Durr 
94],  and  Object-Z  [Duke  95].  Thus,  there  are  signs  that  these  “formal”  methods  are  begin¬ 
ning  to  be  applied  to  the  specification  of  software  components. 

5.2.2  Specifying  Synchronization 

Although  the  above  techniques  allow  for  the  behavioral  specification  of  components,  they 
deal  only  with  sequential  aspects.  This  will  prove  insufficient,  as  systems  are  increasingly 
distributed  and  concurrent. 

Specifying  synchronization  of  components  is  more  of  a  challenge  and  is  even  less  well  un¬ 
derstood  than  the  methods  mentioned  above.  The  Object  Calculus  [Lano  97]  has  been  pro¬ 
posed  to  meet  this  need.  Other  approaches  to  solving  this  problem  involve  the  use  of  Hoare’s 
Communicating  Sequential  Processes  (CSP)  [Allen  97]  or  Milner’s  pi-calculus  [Canal  97, 
Henderson  97,  Lumpe  97],  This  latter  approach  has  led  to  the  development  of  a  composition 
language  called  Piccola  [Acher  99]  that  does  seem  to  be  particularly  relevant  to  the  problem 
of  component  composition.  Along  similar  lines,  an  architectural  style  description  language 
(ASDL)  for  giving  syntactic  and  semantic  information  about  the  components  of  a  software 
system,  and  the  relationships  between  those  components,  using  a  combination  of  Z  and  CSP, 
has  been  proposed  by  Rice  and  Seidman  [Rice  99]. 

5.2.3  Specifying  Quality  of  Service 

According  to  Beugnard  et.  al.,  quality  of  service  includes  attributes  such  as  maximum  re¬ 
sponse  delay,  average  response,  and  precision.  We  might  generalize  this  a  bit  to  include 
quality  attributes.  Quality  attributes  include  quality  of  service  as  well  as  global  attributes  of  a 
component  such  as  its  portability,  adaptability  and  so  forth. 

The  specification  of  quality  attributes  is,  perhaps,  even  more  of  a  research  issue  and  less 
widely  undertaken  than  the  specification  of  the  behavior  or  synchronization.  One  notation 
that  can  be  applied  to  this  problem  is  called  NoFun  [Franch  98].  This  notation  allows  the 
definition  of  non-functional  attributes  of  software.  Among  the  most  widely  accepted  such 
attributes  are:  time  and  space  efficiency,  reusability,  maintainability,  reliability,  and  usability. 
Having  defined  these  attributes  for  a  piece  of  software,  NoFun  then  allows  the  non-functional 
behavior  of  a  component  to  be  defined  with  respect  to  the  attributes. 

Although  a  formal  notation  for  quality  attributes  is  still  a  matter  of  speculation,  Szyperski 
sites  the  example  of  Swiss  banks  specifying  the  required  service  level  of  a  component  sub- 
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contracted  out  to  a  third  party  [Szyperski  98b].  This  covers  guarantees  of  availability,  mean 
time  between  failures,  mean  time  to  repair,  throughput,  capacity,  latency,  data  safety  for  per¬ 
sistent  state,  etc.  Finally,  in  the  field  of  performance  specification,  it  may  be  possible  to  spec¬ 
ify  the  complexity  of  a  component.  The  Apple/SANE™  libraries  specified  the  computational 
complexity  of  various  library  functions. 

5.3  Credentials 

The  bewildering  variety  of  attempts  to  increase  the  accuracy  and/or  scope  of  interface  speci¬ 
fications  suggests  that  no  consensus  has  yet  emerged  on  how  to  describe  the  properties  of 
modules  (or  components).  With  increased  scope  and  accuracy  comes  (it  seems)  increased 
formality,  which  in  turn  leads  to  greater  complexity  and  the  need  for  still  more  specialized 
skills.  A  very  different  position  was  taken  by  Mary  Shaw,  who  argued  for  credentials  as  a 
form  of  interface  specification  [Shaw  96].  Informally,  a  credential  is  a  <name,  value,  confi- 
dence>  triple,  where  name  refers  to  the  name  of  the  property,  value  refers  to  the  way  this 
property  is  manifested  by  a  particular  component,  and  confidence  refers  to  different  degrees 
of  certainty  attached  to  the  name/value  pair.  Shaw's  argument  was  that  interface  specifica¬ 
tions  for  “architectural  components”  (sic)  (by  which  she  means  “large”)  are  inherently  in¬ 
complete,  given  the  limitations  of  current  specification  formalisms,  the  complexity  architec¬ 
tural  components,  and  the  variety  of  different  ways  that  a  component  will  be  used. 

Shaw  envisions  a  kind  of  lingua  franca  of  credentials,  with  standard  properties  and  well- 
defined  measurement  scales  for  these  properties, 
tional  property  of  a  module  might  be  that  it 
provides  a  particular  service.  This  becomes  a 
fact  that  might  be  known  with  great  accuracy, 
for  example  <service,  sort,  demonstrated> 
states  that  the  module  has  a  service  called 
“sort”  and  that  this  service  has  been  demon¬ 
strated  in  a  sample  program.  However,  de¬ 
scribing  properties  can  become  a  complicated 
matter.  In  particular,  properties  are  not  neces¬ 
sarily  atomic  but  are  sometimes  aggregate.  For 
example,  a  property  of  the  service  might  be  its  performance  under  a  particular  security  level, 
or  its  accuracy  under  a  particular  performance  level.  For  N  extra-functional  properties  of  a 
service  there  are  as  many  as  2N  aggregations  of  these  properties.  Even  though  only  a  small 
subset  of  these  may  have  independent  meaning,  it  will  be  difficult  to  itemize  these  aggrega¬ 
tions  to  say  nothing  of  naming  them.  Note,  however,  that  Shaw  argued  that  such  complete¬ 
ness  was  impractical  if  not  impossible. 

Thus,  although  credentials  can  not  be  a  complete  answer,  the  idea  is  useful  for  at  least  two 
reasons.  First,  the  distinction  between  truth  and  knowledge  may  be  crucial  in  component- 
based  systems.  The  distinction  is  certainly  important  to  the  issue  of  component  certification 
since  there  will  likely  be  a  cost  versus  confidence  tradeoff  made  in  certifying  properties  that, 


Take  the  illustration  below.  A  simple  func- 


14 


CMU/SEI-2000-TR-008 


for  the  present  at  least,  resist  formal  specification  or  verification  techniques.  Second,  the 
open-ended  nature  of  credentials  nicely  mirrors  a  much  earlier  argument  made  by  Pamas  that 
a  module’s  interface  is,  essentially,  the  set  of  assumptions  that  can  be  made  about  that  module 
[Pamas  71].  The  views  of  Shaw  and  Pamas  take  us  away  from  the  narrow  perspective  of  in¬ 
terface  as  formal  specification,  and  suggest  the  need  for  a  more  flexible  way  of  describing 
component  interfaces. 


5.4  Components  and  Multiple  Interfaces 

Interestingly,  Shaw’s  credentials  blur  the  distinction  between  a  module’s  implementation  and 
its  interface.  This  blurring  runs  counter  to  developments  in  software  component  technology 
where  there  is  a  clear  distinction  between  (and  separation  of)  interface  and  implementation. 
The  separation  we  refer  to  is  much  stronger  than  that  suggested  by  languages  that  support 
separate  compilation  of  interfaces  and  implementations,  for  example,  C++  header  files  or 
Ada  package  specifications.  In  languages  and  systems  that  support  software  components  an 
interface  may  be  implemented  by  many  distinct  components  and  a  component  many  imple¬ 
ment  many  distinct  interfaces. 

One  concrete  realization  of  this  idea  is  found  in  Microsoft’s  Component  Object  Model 
(COM).  In  COM,  interface  specifications  are  assigned  a  globally  unique  identifier  (GUID)  at 
the  time  they  are  created;  each  revision  of  that  interface  is  assigned  a  new  GUID.  Compo¬ 
nents  are  binary  implementations  (COM  is  a  binary  standard)  that  are  bound  to  the  interfaces 
they  implement  via  these  interface  GUIDs.  Similarly,  clients  are  linked  to  components  via 
interface  GUIDs.  Thus  there  is  a  clean  separation  of  interface  and  component,  with  clients 
and  component  alike  bound  directly  to  interfaces  and  only  indirectly  to  each  other.  The  Java 
programming  language  also  distinguishes  interface  specification  from  class  specification  by 
introducing  an  interface  type.  In  both  COM  and  Java  the  idea  is  that  clients  depend  upon  in¬ 
terfaces  and  never  upon  implementations,  and  that  components  can  implement  any  arbitrary 
number  of  interfaces. 


But  as  we  have  seen  from  the  discussion  above,  a  complete  separation  is  difficult  or  impossi¬ 
ble  to  achieve  in  practice:  a  module  implementation  will  have  properties  in  addition  to  those 
specified  on  an  abstract  interface.  Invariably,  component  implementations  introduce  new 
properties  that  might  “bleed  through”  the  inter-  Interface  Y 

face.  For  example,  assuming  that  an  interface 
specification  language  could  express  perform¬ 
ance  properties  (neither  Java  nor  Microsoft 
IDL,  the  language  used  to  describe  COM  inter¬ 
faces,  can  do  so),  an  interface  may  stipulate  that 
a  particular  sorting  operation  must  exhibit  com¬ 
plexity  no  worse  than  M»/og(N).  Even  if  a 
component  were  compliant  with  this  property 
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(and  we  would  need  to  be  precise  about  what  this  means),  it  would  nonetheless  bind  a  par¬ 
ticular  value  to  M.  This  binding  would,  in  effect,  change  the  performance  property  of  the 
interface,  since  the  client  could  conceivably  come  to  depend  upon  this  particular  binding. 

There  are  more  formal  ways  of  expressing  interface  bleed,  but  the  point  is  that  it  is  crucial  to 
distinguish  between  abstract  interfaces  (those  that  are  described  independent  of  any  imple¬ 
mentation)  and  bound  interfaces  (those  that  are  associated  with  an  implementation).  This  dis¬ 
tinction  is  an  essential  one  for  certification,  composition  and  system  analysis. 

Summary  of  Key  Points 

Interfaces  describe  those  properties  of  a  component  that  might  lead  to  inter-component  de¬ 
pendencies.  However,  the  state  of  the  art  of  interface  specification  is  still  quite  limited  in  its 
ability  to  describe  the  properties  of  components;  hence  unexpected  dependencies  may  arise 
(“property  bleed”).  This  is  especially  true  where  quality  of  service  properties  are  concerned. 
It  is  therefore  important  to  distinguish  abstract  interface,  which  are  independent  of  an  imple¬ 
mentation,  and  bound  interfaces,  which  are  associated  with  an  implementation  and  therefore 
may  exhibit  properties  not  found  in  the  abstract  interface. 
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6  Contracts 


Interfaces  were  described  earlier  as  specifying  a  one-way  flow  of  dependencies  from  modules 
that  implement  services  to  the  clients  that  use  these  services.  That  is,  the  client  has  some  as¬ 
sumptions  about  the  service  and  hence  comes  to  depend  upon  these  assumptions,  while  the 
module  interface  specifies  those  assumptions  that  are,  in  some  way,  sanctioned  by  the  de¬ 
signer  of  the  module.  However,  it  is  more  accurate  to  say  that  a  client  and  module  are  co¬ 
dependent.  That  is,  a  client  depends  upon  a  module  to  provide  a  service  in  a  certain  way,  and 
the  module  depends  upon  the  client  to  access  and  use  these  services  in  a  certain  way. 

While  co-dependence  is  a  factor  in  even  simple  client/module  interactions,  its  implication  to 
component-based  software  is  magnified  because  of  the  premium  placed  on  component  sub¬ 
stitutability,  and  because  the  component  interactions  that  define  the  context  in  which  substi¬ 
tution  occurs  can  be  significantly  more  complex  than  in  traditional  systems.  It  is  partly  in 
recognition  of  this  that  the  idea  of  interface  contract  has  become  prominent  in  component- 
based  research  literature.  To  be  sure,  the  idea  of  interface  contract  predates  software  compo¬ 
nent  technology,  but,  as  will  be  seen,  it  has  taken  on  new  life  in  this  new  context. 

Interface  contract  is  a  metaphor  with  connotations  that  are  useful  to  CBSE.  For  example 

•  Contracts  are  between  two  or  more  parties. 

•  Parties  often  negotiate  the  details  of  a  contract  before  becoming  signatories. 

•  Contracts  prescribe  normative  and  measurable  behaviors  on  all  signatories. 

•  Contracts  can  not  be  changed  unless  the  changes  are  agreed  to  by  all  signatories. 

The  first  bullet  highlights  the  issue  of  co-dependence,  and  generalizes  this  to  the  more  gen¬ 
eral  case  that  arises  in  component-based  systems  where  multiple  components  coordinate  to 
implement  a  single,  logical  interaction.  The  second  bullet  can  be  useful  in  understanding 
component  composition,  as  all  parties  must  agree  to  any  “bleed  through”  properties  intro¬ 
duced  by  a  component  that  implements  an  otherwise  abstract  interface.  The  third  bullet  has 
implications  for  component  certification,  and  the  last  bullet  on  stable  standards  for  building 
markets  for  components. 

There  are  no  doubt  other  connotations  as  well,  but  these  serve  to  motivate  what  contracts  are 
about.  The  following  discussion  focuses  on  the  first  bullet,  and  in  particular  on  the  idea  of 
specifying  reciprocal  obligations  among  the  parties  of  an  interaction. 
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6.1  Contracts  and  Reciprocal  Obligations 

Component  interaction  involves  a  number  of  (usually)  tacit  agreements  between  a  client  and  a 
component.  For  example,  a  client  depends  upon  the  component  to  provide  a  service,  and  per¬ 
haps  depends  upon  a  number  of  extra-functional  properties  as  well.  In  return,  the  component 
may  depend  upon  the  client  to  provide  data  arguments  within  certain  bounds  or  to  have  prop¬ 
erly  initialized  the  component  service.  To  some  extent  these  co-dependencies  can  be  specified 
in  an  API  through  the  use  of  an  assertion  language,  most  commonly  the  use  of  pre-  and  post¬ 
conditions.  A  contractually  specified  interface  makes  these  co-dependencies  explicit. 


1  INTERFACE  Directory;  (*  introduce  a  new  interface  type  *) 

2  IMPORT  Files;  (*  import  an  existing  interface  type  *) 

3  TYPE  Name=ARRAY  OF  CHAR; 

4 

5  PROCEDURE  ThisFile (n:Name) : Files . File; 

6  (*  PRE  n/=" " ) 

7  (*  POST  result=File  named  n  OR  result=NIL  AND  no  such  file  *) 

8 

9  PROCEDURE  AddEntry(n: Name;  f : Files . File) ; 

10  (*  PRE  n/= " "  AND  f=/NIL  *) 

11  (*  POST  ThisFile (n) =f  *) 

12 

13...  other  details  deleted 
14  END  Directory; 


Figure  2:  Contractually  Specified  Interface  (Fragment) 

Consider  the  example  interface  in  Figure  2,  adapted  from  Szyperski4  [Szyperski  98].  This 
interface  specification  describes  a  number  of  functional  properties  of  a  component  that  pro¬ 
vides  a  directory  service — specifically,  the  names  and  signatures  of  two  operations  of  the  di¬ 
rectory  service  (lines  5  and  9).  Also  specified  are  behavioral  properties  that  are  related  to 
these  operations;  these  are  specified  in  an  assertion  language  of  pre-  and  post-conditions  that 
are,  in  this  illustration,  embedded  as  comments  in  the  language  of  the  API  specification.  Note 
that  the  specification  of  a  contract  does  not  depend  upon  the  use  of  pre-  and  post-conditions. 
Other  techniques  have  been  used;  for  example,  a  set  of  rules  that  map  sequences  of  input 
events  to  sequences  of  output  events  [Berry  98]. 

Returning  to  Figure  2,  the  post-condition  for  the  AddEntry  ( )  operation  (line  11)  asserts 
that  after  invoking  this  operation  a  file  can  be  retrieved  at  some  future  time  using  the  This¬ 
File  ( )  operation  (line  5).  The  post  condition  for  the  ThisFile  ( )  operation  (line  7)  as¬ 
serts  that  it  returns  a  file  of  a  given  name  or  else  it  returns  no  file,  in  which  case  the  operation 
guarantees  that  no  such  file  of  that  name  exists  within  the  directory.  Thus,  the  post  conditions 
specify  properties  of  the  directory  service  that  clients  may  depend  upon.  In  contrast,  pre¬ 
conditions  specify  those  properties  that  the  directory  service  requires  of  the  client.  For  exam- 


4  We  have  altered  the  illustration  slightly  for  the  purposes  of  this  discussion. 
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pie,  the  precondition  for  AddEntry  ( )  operation  (line  10)  is  that  a  client  provide  a  valid  file 
name  and  file  object.  In  a  real  sense,  the  directory  service  depends  upon  the  client  to  satisfy 
this  precondition.  Earlier  it  was  demonstrated  that  dependencies  arise  from  assumptions 
about  properties  and  that  a  specification  of  these  properties  is,  by  definition,  an  interface 
specification.  So,  the  preconditions  in  Figure  2  specify  an  interface  (a  specification  of  prop¬ 
erties)  that  it  requires  clients  of  the  directory  service  to  possess. 

Thus,  it  is  useful  to  think  of  an  interface  specification  as  comprising  a  provides  part  and  a 
requires  part.  This  is  depicted  graphically  to  the  right  for  directory  component  D  and  a  client 
component  C.  In  this  illustration  D  warrants  that  it  will  implement  the  provides  part  (labeled 
as  PROd  in  the  graphic),  but  to  do  so  it 
needs  C  to  implement  the  requires  part  (la¬ 
beled  REQd).  Likewise  C  has  its  own  inter¬ 
face  comprised  of  provides  and  requires 
parts,  labeled  PROcand  REQC,  respectively. 

For  D  and  C  to  interact  C  must  provide  what  D  requires,  and  D  must  provide  what  C  requires. 
The  directory  service  provides  an  operation  AddEntry  ( )  but  it  requires  that  client  compo¬ 
nents  call  this  operation  with  file  names  that  are  non-empty  strings;  the  client  provides  that  it 
will  do  so. 

The  contract  specified  in  Figure  2  specifies  reciprocal  obligations  between  a  directory  service 
and  clients  of  that  service.  In  doing  so  it  also  specifies  a  simple  interaction  model,  and  the 


1  DEFINITION  Directory;  (*  introduce  a  new  interface  type  *) 

2  IMPORT  Files;  (*  import  an  existing  interface  type  *) 

3  IMPORT  Notifier;  (*  interface  type  for  callbacks  *) 

4  TYPE  Name = ARRAY  OF  CHAR; 

5 

6 

7  PROCEDURE  Init ( ) ; 

8  (*  PRE  True  *) 

9  (*  POST  Init=True  *) 

10 

11  PROCEDURE  ThisFile(n:Name) : Files. File; 

12  (*  PRE  Init=True  AND  n/="") 

13  (*  POST  result=File  named  n  OR  result=NIL  AND  no  such  file  *) 

14 

15  PROCEDURE  AddEntry (n: Name;  f :Files . File) ; 

16  (*  PRE  Init=True  AND  n/=“"  and  f=/NIL  *) 

17  (*  POST  ThisFile (n) =f  AND  FORALL  Notifiers  CB :  CB. Notify (n) *) 

18 

19  PROCEDURE  RegisterNotif ier (CB :Notif ier ) 

20  (*  PRE  CB/=NIL  *) 

. .  .other  details  deleted 
END  Directory; 


Figure  3:  Extended  Contract  with  More  Explicit  Patterns  of  Interaction 
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obligations  that  a  directory  and  service  must  fulfill  to  participate  in  the  interaction  model.  A 
simple  interaction  is  specified  by  the  pre-  and  post  conditions  of  the  operation:  if  the  client 
provides  a  valid  name,  then  the  operation  will  return  a  file  or  NIL.  Contracts  may  also  specify 
more  complex  patterns  of  interaction.  By  pattern  of  interaction  we  mean  a  sequence  of  inter¬ 
actions  among  two  or  more  components  that  obey  some  specified  rules.  The  ThisFile  ( ) 
interaction  is  a  trivial  pattern  of  interaction — it  involves  only  two  components,  the  directory 
component  and  the  client  component,  and  applies  only  to  a  single  invocation  of  This¬ 
File  ( ) . 

More  complex  patterns  of  interaction  are  illustrated  (as  highlighted  text)  in  Figure  3,  which 
extends  the  contract  shown  in  Figure  2.  For  example,  the  preconditions  on  ThisFile  ( ) 
(line  12)  ensures  that  that  prior  to  calling  init  ( )  no  interactions  involving  ThisFile  ( ) 
are  allowed.  Similarly,  AddNotif  ier  ( )  and  the  interface  type  Notif ier  introduce  a 
pattern  of  interaction  commonly  referred  to  as  a  callback.  This  pattern  of  interaction  involves 
the  Directory  component  and  an  unspecified  number  of  components  that  implement  the  No¬ 
tif  ier  interface,  each  of  which,  after  being  registered  with  AddNotif  ier  ( ) ,  will  be 
called  whenever  the  AddEntry  ( )  operation  is  invoked  by  any  client  (line  17).  Thus  a  pat¬ 
tern  of  interaction  may  span  several  components  and  several  invocations.  Arbitrarily  complex 
patterns  of  interaction  may  be  specified  in  a  component  contract. 

6.2  Two  Senses  of  Contract 

The  contracts  in  Figures  2  and  3  may  have  specified  a  pattern  of  interaction,  but  the  pattern  is 
rooted  on  the  specified  component.  This  points  to  two  distinct  senses  of  contract,  one  where 
the  subject  of  the  contract  is  a  component  and  the  other  where  the  subject  is  the  interaction 
itself.  For  lack  of  better  terms  we  will  denote  the  former  as  a  component  contract  and  the 
latter  as  an  interaction  contract. 

Component  contracts  are  natural  and  necessary.  A  supplier  of  components  needs  to  describe 
the  services  offered  by  a  component  and 
its  other  properties.  The  contractual 
specification  of  that  component  goes 
further  and  also  describes  the  conditions 
that  must  hold  for  that  component  to 
work  properly.  Component  contracts  are 
necessary,  even  though  a  component 
model  may  impose  some  or  all  of  the 
interfaces  required  of  a  component.  For 
as  we  have  already  noted,  a  component 
implementation  will  introduce  other 
properties,  including  obligations  on  other 
components,  not  specified  by  a  component  model. 


f  A  component  contract  specifies 
1  a  pattern  of  interaction  rooted 
f  on  that  component.  The  con- 
j  tract  specif  ies  the  services 
I  provided  by  a  component  and 
j  the  obligations  of  clients  and 
f  the  environment  needed  by  a 
|  component  to  provide  these 
|  services.  ; 
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Where  component  contracts  describe  components,  which,  as  we  know  from  an  earlier  defini¬ 
tion,  are  implementations,  interaction  contracts  specify  the  reciprocal  obligations  among  in¬ 
terface  types  that  may  be 

implemented  by  arbitrary  An  interaction  contract  specif  ies  a 
components,  interaction  pattern  of  interaction  ainong  different 

contracts  play  the  role  of  roles,  and  the  reciprocal  obligations  of 

design  specification  that  components  that  fill  these  roles. 

will  be  “filled  in”  by  com¬ 
ponents.  Since  a  component  can  implement  multiple  interface  types,  it  can  “fill”  several  such 
roles.  Thus,  each  interaction  contract  describes  a  pattern  of  interaction  among  different  roles 
in  a  system.  Component  models  such  as  EJB™  define  interaction  models  (and  hence  con¬ 
tracts)  between,  for  example,  Containers  and  SessionBeans.  It  is  interesting  to  note  that  the 
term  contract  is  most  often  used  to  describe  component  contract  sense,  but  the  original  sense 
of  the  term  more  closely  follows  the  interaction  contract  sense  [Holland  92].  Nonetheless, 
D’Souza’s  influential  CBSE  design  methodology  has  a  separate  notation  for  interaction  con¬ 
tracts  [D’ Souza  99].  Berry  and  Kaplan’s  Finesse  language  and  environment  provides  a  way 
of  specifying  both  senses  and  combining  them  [Berry  98]. 


Summary  of  Key  Points 

Contracts  shift  the  focus  from  specification  of  components  to  specification  of  patterns  of  in¬ 
teractions,  and  the  mutual  obligations  of  participants  in  these  interactions.  There  are  two 
senses  of  contract  that  are  necessary  to  CBSE:  component  contacts  and  interaction  contracts. 
Component  contracts  describe  patterns  of  interaction  that  are  rooted  on  a  component.  Inter¬ 
action  contracts  describe  abstract  patterns  of  interaction  among  roles  that  are  filled  by  com¬ 
ponents.  Systems  are  assembled  from  components  through  a  process  of  filling  roles  with 
components. 
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7  Component  Models  and  Frameworks 


There  is  some  terminological  confusion  in  the  literature  concerning  component  models  and 
frameworks.  As  already  noted,  Week  disdains  to  distinguish  these  concepts,  preferring  to 
define  a  component  framework  as  standards  and  conventions  that  may  or  may  not  include 
support  services  [Week  96],  D’Souza  and  Wills  use  the  term  component  kit  in  a  similar  vein 
to  Week’s  framework,  and  use  the  term  component  model  to  refer  to  the  interfaces,  assump¬ 
tions  and  so  forth  of  individual  components — that  is,  each  component  has  its  own  component 
model  [D'Souza  99,  Wills  99].  Nevertheless,  these  are  differences  in  how  categories  are  la¬ 
beled  rather  than  in  the  categories  themselves.  There  is  consensus  that  component-based 
systems  rely  upon  well-defined  standards  and  conventions  (what  we  call  a  component  model) 
and  a  support  infrastructure  (what  we  call  a  component  framework). 

A  component  model  specifies  the  standards  and  conventions  imposed  on  developers  of  com¬ 
ponents.  Compliance  with  a  component  model  is  one  of  the  properties  that  distinguish  com¬ 
ponents  (as  we  use  the  term)  from  other  forms  of  packaged  software.  A  component  frame¬ 
work  is  an  implementation  of  services  that  support  or  enforce  a  component  model.  Both  are 
examined  more  closely,  below. 

7.1  What  are  Component  Models? 

There  is  as  yet  no  agreement  on  what  should  or  must  be  included  in  a  component  model.  We 
can  obtain  some  leverage  on  this  question  by  being  more  explicit  about  the  purpose  of  a 
component  model — what  is  it  that  we  expect  to  achieve  by  imposing  standards  and  conven¬ 
tions  on  component  developers? 

Uniform  composition.  Two  components  can  interact  if  and  only  if  they  share  consistent  as¬ 
sumptions  about  what  each  provides  and  each  requires  of  the  other.  Obviously  some  of  these 
assumptions  will  refer  to  some  unique  aspect  of  each  component,  usually  the  function  com¬ 
puted  by  a  component.  But  there  are  other  assumptions  that  might  be  standardized  across  all 
components,  thereby  reducing  chances  for  accidental  mismatches  that  inhibit  composition  of 
components.  These  standards  might  address  how  components  are  located,  how  control  flow 
is  synchronized,  which  communication  protocol  is  used,  how  data  is  encoded  and  so  forth. 

Appropriate  quality  attributes.  It  is  a  matter  of  general  agreement  that  the  quality  attributes 
of  a  system  will  depend  upon  its  “software  architecture.”  Standardizing  the  types  of  compo¬ 
nent  used  in  a  system  and  their  patterns  of  interaction — what  has  been  defined  as  architec¬ 
tural  style  — is  one  way  to  ensure  that  a  system  composed  from  third-party  components  will 
possess  the  desired  quality  attributes  [Bass  98].  Closely  related  to  quality  attributes  is  quality 
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of  service,  which  can  also  be  obtained  by  specifying  that  patterns  of  interaction  are  transac¬ 
tional,  or  encrypted,  and  so  forth. 

Deployment  of  components  and  applications.  The  success  of  CBSE  depends  on  the  emer¬ 
gence  of  a  robust  market  in  third-party  components.  A  precondition  for  component  composi¬ 
tion  is  that  components  can  be  deployed  from  the  developer  environment  into  the  composi¬ 
tion  environment,  and  that  applications  that  have  been  composed  from  components  can  be 
deployed  from  the  composition  environment  into  the  customer  environment.  This  is  part  of 
the  motivation  for  component  frameworks — they  provide  a  standard  compose-time  and  run¬ 
time  infrastructure  that  will  clearly  simplify  the  deployment  of  components  and  applications. 

Given  the  above  motivations,  component  models  will  impose  standards  and  conventions  of 
the  following  kind: 

•  Component  types.  A  component’s  type  may  be  defined  in  terms  of  the  interfaces  it  imple¬ 
ments.  If  a  component  implements  three  different  interfaces  X,  Y  and  Z,  then  it  is  of  type 
X,  Y  and  Z.  Moreover,  a  component  that  implements  X,  Y  and  Z  is  polymorphic  with  re¬ 
spect  to  these  types — it  can  play  the  role  of  an  X,  Y,  or  Z  at  different  times.  This  is  an  im¬ 
portant  aspect  of  components  found  in  both  Microsoft/COM  and  Sun/Java  technologies.  A 
component  model  requires  that  components  implement  one  or  more  interfaces,  and  in  this 
way  a  component  model  can  be  seen  to  define  one  or  more  component  types.  Different 
component  types  can  play  different  roles  in  systems,  and  participate  in  different  types  of 
interaction  schemes  (see  next  item). 

•  Interaction  schemes.  Component  models  will  specify  how  components  are  located,  which 
communication  protocols  are  used,  and  how  qualities  of  service  such  as  security  and 
transactions  are  achieved.  The  component  model  may  describe  how  components  interact 
with  each  other,  or  how  they  interact  with  the  component  framework.  The  former  class  of 
interactions  includes  constraints  on  which  component  types  can  be  clients  of  other  types, 
the  number  of  simultaneous  clients  allowed,  and  so  forth  (topology  constraints).  The  latter 
class  of  interaction  includes  things  relating  to  resource  management  such  as  component 
lifecycle  (activation,  deactivation),  thread  management,  persistence  and  so  forth.  Interac¬ 
tion  schemes  may  be  common  across  all  component  types  or  unique  to  particular  compo¬ 
nent  types. 

•  Resource  binding.  The  process  of  composing  components  is  a  matter  of  binding  a  compo¬ 
nents  to  one  or  more  resources.  A  resource  is  either  a  service  provided  by  a  framework  or 
by  some  other  component  deployed  in  that  framework.  A  component  model  describes 
which  resources  are  available  to  components,  and  how  and  when  components  bind  to 
these  resources.  Conversely,  a  framework  sees  components  as  resources  that  must  be 
managed.  Thus,  deployment  is  the  process  by  which  frameworks  are  bound  to  compo¬ 
nents,  and  a  component  model  will  describe  how  components  are  deployed. 
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7.2  Component  Framework 

A  good  way  to  think  of  a  component  framework  is  as  a  mini-operating  system.  In  this  anal¬ 
ogy,  components  are  to  frameworks  what  processes  are  to  operating  systems.  The  framework 
manages  resources  shared  by  components,  and  provides  the  underlying  mechanisms  that  en¬ 
able  communication  (interaction)  among  components.  Like  operating  systems,  component 
frameworks  are  active  and  act  directly  upon  components  in  order  to  manage  a  component’s 
lifecycle  or  other  resources,  for  example  to  start,  suspend,  resume,  or  terminate  component 
execution.  However,  unlike  general-purpose  operating  systems  such  as  Unix,  which  support 
a  rich  array  of  interaction  mechanisms5,  component  frameworks  are  specialized  to  support 
only  a  limited  range  of  component  types  and  interactions  among  these  types.  In  exchange  for 
a  loss  in  flexibility  there  is  improved  prospects  for  component  composition. 

Although  this  is  a  good  analogy,  and  holds  up  well  when  used  to  describe  a  variety  of  com¬ 
ponent-based  technologies,  there  are  other  possible  realizations  of  component  framework.  It 
is  not  necessary  that  the  framework  have  a  runtime  existence  independent  of  components. 

For  example,  the  framework  implementation  may  be  bundled  with  the  component  imple¬ 
mentation.  An  example  of  this  can  be  found  in  [Koutlis  98],  where  a  component-based  sys¬ 
tem  originally  implemented  in  the  OpenDoc  framework  was  re-hosted  to  a  Java  implementa¬ 
tion.  In  the  re-hosted  version  the  component  types  and  coordination  schemes  were 
implemented  as  Java  classes  that  were  invoked  by  components.  Nevertheless,  the  trend  in 
component  technologies  seems  to  be  towards  framework  as  independent  implementation, 
making  the  operating  system  analogy  quite  apt. 

Many  examples  of  component  frameworks  (of  the  “operating  system”  sort)  can  be  seen  in 
practice.  The  Enterprise  JavaBeans™  (EJB)  specification  defines  a  framework  of  servers 
and  containers  to  support  the  EJB  component  model,  with  servers  responsible  for  providing 
persistence,  transaction  and  security  services  while  containers  are  responsible  for  managing 
component  life  cycle6.  The  WaterBeans  component  framework  is  specialized  to  component 
interactions  for  real-time  visualization  of  data  streams,  and  visual  composition  of  compo¬ 
nents.  The  WaterBeans  framework  supports  high-performance  data  streams  and  calculates 
execution  schedules;  based  on  these  schedules  it  invokes  component  operations  to  fill  these 
streams.  And  of  course  Microsoft's  VisualBasic  framework,  which  is  specialized  for  visual 
composition  of  components  (called  VBXs)  rather  than  for  any  particular  runtime  quality  at¬ 
tribute,  is  perhaps  the  most  successful  commercial  framework  yet  produced.  In  this  case  the 
framework  is  the  VisualBasic  interpreter  for  scripting  and  composition  coupled  with  the 
COM  deployment  and  communication  services  provided  by  the  native  operating  system. 

Note  that  the  overtly  component-based  illustrations  above  have  analogues  in  established 
software  engineering  practice.  For  example.  Simplex  is  a  component  framework  but  for  the 


5  These  are  often  referred  to  as  interprocess  communication  mechanisms,  and  in  the  case  of  Unix 

includes  signals,  remote  procedure  calls,  pipes,  sockets,  shared  memory  and  the  file  system. 

6  To  date,  commercial  implementations  of  EJB  bundle  server  and  container  into  one  “framework.” 
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fact  that  the  replacement  units  it  manages  do  not  fully  satisfy  our  above-stated  definition  of 
component  [Sha  95].  The  Simplex  “framework”  supports  online  upgrade  of  components 
while  maintaining  fault-tolerant,  real-time  behavior.  Similarly,  many  cyclic  executives  and 
other  minimal  operating  systems  that  were  developed  for  real-time  systems  are  essentially 
component  frameworks.  The  motivation  for  developing  all  of  these  is  the  same:  to  ensure 
control,  and  hence  predictability,  of  one  or  more  quality  attributes  (fault  tolerance  and  real¬ 
time  performance  in  the  case  of  Simplex,  real-time  performance  in  the  case  of  cyclic  execu¬ 
tives).  This  is  also  the  motivation  for  developing  custom  component  frameworks. 

7.3  Custom  Frameworks  and  Programmable 
Middleware 

Tension  exists  between  two  tendencies  in  software  component  technology:  standard  versus 
custom  component  models  and  frameworks. 

On  the  one  hand,  we  have  argued  that  component  models  have  a  natural  correlation  with  the 
idea  of  architectural  style.  Just  as  different  architectural  styles  or  combinations  of  styles  are 
needed  to  achieve  different  mixes  of  quality  attributes  in  systems,  so  too,  it  would  seem,  dif¬ 
ferent  component  models  and  supporting  frameworks  are  needed  for  the  very  same  reason. 
Minimally,  this  would  argue  for  a  catalogue  of  component  models  and  off-the-shelf  frame¬ 
works.  This  argument  is  well  supported  in  the  literature  [Baggiolini  97,  Gannon  98,  Garlan 
98,  Lycett  98,  Olken  98,  Szyperski  98a,  Yucel  98,  Fellner  99,  Lauder  99,  Plakosh  99].  In  fact, 
the  tendency  in  these  illustrations  argues  that  no  simple  catalogue  will  suffice,  but  that  in¬ 
stead  what  is  needed  is  a  technique  for  constructing  component  models  from  a  kit  of  model 
fragments  known  to  support  particular  quality  attributes  (see  closely  related  ideas  about  at¬ 
tribute-based  architectural  styles)  [Klein  00]. 

On  the  other  hand,  this  tendency  toward  differentiation  of  component  models  runs  counter  to 
what  is  needed  to  establish  a  robust  market  in  software  components:  standard  component 
models  and  frameworks.  Besides  being  intuitively  obvious,  the  need  for  viable  component 
standards  is  described  in  Szyperski  and  elsewhere  [Szyperski  98b,  Bellur  98].  Simply  put, 
component  developers  need  a  “sufficiently  large”  market  for  deploying  their  products.  Al¬ 
though  what  is  “sufficiently  large”  may  vary  across  business  sectors  and  component  types,  a 
market  fragmented  into  a  number  of  non-standard  frameworks  will  certainly  inhibit  the 
emergence  of  component  markets.  Norman  makes  the  case  that  standard  “non-substitutable” 
infrastructures  are  needed  (frameworks)  to  support  markets  in  substitutable  products  (compo¬ 
nents)  and  he  backs  up  this  argument  with  numerous  illustrations  from  the  time  of  Thomas 
Edison  to  current  computing  technologies7  [Norman  98].  He  also  argues  that  competition  in 
non-substitutable  infrastructures  is  “winner  take  all,”  and  that  technologies  will  often  fail 
where  no  such  winner  emerges  (again,  he  sites  numerous  examples). 


7  Although  Norman  was  arguing  for  information  appliance  technologies  his  arguments  apply  with 
equal  force  to  component  technologies. 


26 


CMU/SEI-2000-TR-008 


So  how  is  this  tension  between  variation  in  quality  attribute  requirements  and  the  need  for 
standard  component  models  and  frameworks  to  be  resolved?  One  way  is  to  adopt  a  “wait  and 
see”  attitude  and  hope  that  the  market  produces  component  standards  in  market  sectors  that 
are  sufficiently  large  and  cohesive  to  benefit  from  such  standards.  This  is  a  reasonable  ap¬ 
proach,  given  that  the  impetus  for  component  technology  is  market  pressure  for  reduced 
time-to-market  and  system  development  costs,  rather  than  the  emergence  of  any  particularly 
innovative  technology.  Microsoft’s  COM+  and  Sun's  Enterprise  JavaBeans  have  emerged  to 
address  the  needs  of  management  information  systems  (i.e.,  distributed,  secure,  transactional 
business  logic),  as  has  the  less  proprietary  OMG  component  specification  (as  yet  not  imple¬ 
mented  in  commercial  products).  Component  technologies  are  also  emerging  in  more  nar- 

8 

rowly-scoped  market  sectors,  for  example  geographic  information  systems. 

There  are  also  technological  approaches  to  resolving  this  tension.  One  approach  is  to  treat 
component  frameworks  as  an  assembly  of  components  rather  than  as  a  monolithic  infra¬ 
structure.  Robben  proposes  a  scheme  based  in  meta-object  protocols  (MOP)  for  composing 
quality  attributes  from  components  that  implement  each  such  attribute  [Robben  98].  Venkata- 
subramanian  also  proposes  MOP  as  a  means  of  parameterizing  frameworks  to  allow  dynamic 
modification  of  protocols  to  accommodate  context-specific  quality  attribute  requirements 
[Venkatasubramanian  98].  Thompson  et.  al.  describe  an  approach  that  dynamically  inter¬ 
poses  plug-ins  between  web  clients  and  servers  to  provide  quality  of  service  attributes, 
yielding  what  they  call  an  intermediary  architectural  approach  to  frameworks  [Thompson 
98].  These  proposed  techniques  could  be  understood  in  the  context  of  the  “framework  as  op¬ 
erating  system”  analogy:  each  attempts  to  extract  what  should  be  separately  configurable 
(parameterizable)  components  from  the  framework  micro-kernel.  Berry  and  Kaplan  treat  the 
framework  as  a  programmable  abstraction  rather  than  an  assembly  of  components  (i.e.,  “pro¬ 
gramming  the  middleware”)  [Berry  98].  This  is  also  a  plausible  approach  that  has  been  seen 
elsewhere.  See  Bergstra,  for  example  [Bergstra  95]. 

Each  of  the  above  approaches  focuses  on  making  component  frameworks  more  adaptable.  If 
successful,  these  techniques  would  result  in  fewer  standard  frameworks,  each  of  which  can  be 
adapted  to  a  variety  of  quality  attribute  and  quality  of  service  requirements.  Another  ap¬ 
proach  is  to  make  the  components  more  flexible  so  that  they  may  be  more  easily  adapted  to 
different  frameworks.  DeLine  developed  a  method  and  proof  of  concept  prototype  for  flexi¬ 
ble  packaging  to  separate  the  framework-specific  aspects  of  a  component  (the  “packaging”) 
from  the  specific  function  implemented  by  the  component  (the  “ware”)  [Deline  99].  The 
separation  of  packaging  from  ware  is  also  reflected  in  the  more  general  idea  of  aspect- 
oriented  programming  (AOP),  which  allows  separation  of  the  core  functionality  of  a  module 
from  a  specification  of  various  non-functional  aspects  (concurrency,  persistence,  distribution 
and  so  forth)  [Kiczales  97b].  An  aspect  weaver,  essentially  an  intra-component  composition 
mechanism,  composes  component  implementations  from  the  functional  core  and  a  set  of  as¬ 
pects.9  Tarr  et.  al.  describe  an  alternative  approach  to  achieving  separation  of  concerns  which 

8  See  for  example,  http://www.esri.com/news/arcnews/winter9899articles/02-arcinfov8.html. 

9  See  http://wwwtrese.cs.utwente.nl/aop-ecoop98/position.html  to  get  a  sense  of  the  interest  in  AOP. 
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they  refer  to  as  hyperslices  and  hypermodules  [Tarr  99].  A  hyperslice  is  an  encapsulation  of 
some  dimension  of  concern;  hyperslices,  with  the  aid  of  a  composition  rule,  are  composed 
into  hypermodules.  Each  of  the  above  approaches  is  predicated  on  separating  the  functional 
core  of  a  component  from  other  concerns  that  may  be  varied  independent  of  component 
functionality. 

Summary  of  Key  Points 

Component  models  specify  the  design  rules  that  must  be  obeyed  by  components.  These  de¬ 
sign  mles  improve  composability  by  removing  a  variety  of  sources  of  interface  mismatch 
(i.e.,  mismatched  assumptions).  The  rules  ensure  that  system-wide  quality  attributes  are 
achieved,  and  that  components  may  be  easily  deployed  into  development  and  runtime  envi¬ 
ronments.  Component  frameworks  provide  the  services  to  support  and  enforce  a  component 
model. 

A  robust  market  in  software  components  will  require  standard  component  models  and 
frameworks.  However,  experience  has  shown  that  different  application  domains  have  differ¬ 
ent  requirements  for  performance,  security,  availability  and  other  quality  attributes.  This  ar¬ 
gues  the  need  for  more  than  one,  and  possibly  many  component  models  and  frameworks. 
Market  forces  are  working  to  find  application  domains  that  are  sufficiently  large  and  coherent 
to  justify  an  industry-standard  component  model,  but  no  clear  winners  have  yet  emerged. 
Technologies  to  support  adaptability  of  frameworks  to  different  quality  attribute  requirements 
may  serve  to  reduce  the  need  for  competing  frameworks.  Similarly,  technologies  to  support 
adaptability  of  components  to  different  frameworks  may  reduce  the  adverse  consequences  of 
a  fragmented  framework  market. 
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8  Composition 


Composition,  rather  than  integration,  is  the  term  used  in  component-based  development  to 
refer  to  how  systems  are  assembled.  Other  than  being  more  evocative  of  a  development  pro¬ 
cess  based  on  software  building  blocks,  there  is  no  inherent  difference  between  these  terms. 
Nevertheless,  the  term  “composition”  is  preferred  in  this  report  because  it  is  so  widely  used 
in  the  software  component  technology  literature. 

Components  are  composed  so  that  they  may  interact.  As  discussed  earlier,  the  component 
model  specifies  patterns’  types  of  components  and  their  allowable  patterns  of  interactions. 

We  first  examine  a  classification  of  these  patterns  of  interaction  in  order  to  clarify  the  con¬ 
nection  between  component  model  and  component  composition.  We  then  turn  to  a  discussion 
resource  binding,  the  mechanism  by  which  composition  takes  place,  and  in  particular  we  dis¬ 
cuss  the  time  of  resource  binding. 

8.1  Compositional  Forms 

From  the  reference  model  depicted  in  Figure  1  we  identify  two  kinds  of  entities  that  are  com¬ 
posed:  components  and  frameworks.  Given  this,  there  are  three  major  classes  of  interactions 
that  arise  in  component-based  systems: 

•  Component— Component  (C— C):  composition  that  enables  interaction  among  compo¬ 
nents.  These  interactions  deliver  application  functionality,  and  so  the  contracts  that 
specify  these  interactions  might  be  classified  as  application-level  contracts. 

•  Framework-Component  (F-C):  composition  that  enables  interactions  between  a  com¬ 
ponent  framework  and  its  components.  These  interactions  enable  frameworks  to  manage 
component  resources,  and  so  the  contracts  that  specify  these  interactions  might  be  classi¬ 
fied  as  system-level  contracts. 

•  Framework-Framework  (F-F):  composition  that  enables  interactions  between  frame¬ 
works.  These  interactions  enable  composition  of  components  that  are  deployed  in  het¬ 
erogeneous  frameworks,  and  so  these  contracts  might  be  classified  as  interoperation 
contracts. 

There  are  additional  special  cases  that  arise  if  we  allow  higher-order  components  and  frame¬ 
works.  Higher-order  components  would  allow  component  aggregates  (assemblies)  to  be 
treated  as  “first-class”  components  (certified  properties,  contractual  interface,  independently 
deployable,  etc.).  Higher-order  frameworks  correspond  to  Szyperski's  idea  of  tiered  frame¬ 
work;  this  would  become  an  essential  concept  should  numerous  application-specific  compo¬ 
nent  models  emerge  [Szyperski  98b]. 
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The  following  table  itemizes  and  briefly  discusses  the  major  classes  of  contracts,  in¬ 
cluding  the  special  cases.  We  refer  to  these  as  compositional  forms 


Table  1:  Compositional  Forms 
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F 

H— 

1 

Components  must  be  deployed  into  frameworks  before  they 
can  be  composed  or  executed.  The  deployment  contract(s) 

(1)  describes  the  interface  that  components  must  implement 
so  that  the  framework  can  manage  their  resources. 

Component  Deployment 
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FI 
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F2 

Drk 
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Frameworks  may  be  deployed  into  other  frameworks,  cor¬ 
responding  to  Szyperski’s  Tiered  Frameworks.  The  EJB 
specification  partially  realizes  this  idea  with  EJB  containers 
deployed  into  EJB  servers .  Contract  (1)  is  analogous  to  the 
component  deployment  contract. 

(sH-® 

F 

Components  deployed  in  the  same  framework  can  be  com¬ 
posed.  The  composition  contract  (1)  expresses  component- 
and  application-specific  functionality;  the  interaction 
mechanisms  to  support  this  contract  are  provided  by  the 

framework. 

Simple  Composition 

■ 

■ 

R 

jjjRgj 

Support  for  tiered  frameworks  implies  composition  of  com¬ 
ponents  across  frameworks,  whether  across  hierarchical  (as 
illustrated)  or  peer  frameworks.  In  either  case  bridging 
contracts  (1)  are  needed  in  addition  to  composition  con¬ 
tracts  (2)  in  order  for  interactions  to  span  generic  compo¬ 
nent  models. 

1 

Ha 

Heterogeneous  Composition 

F2 

FI 

Frameworks  may  be  treated  as  components,  and  may  be 
composed  with  other  components.  This  form  of  composi¬ 
tion  most  commonly  allows  parameterization  of  framework 
behavior  via  “plug-ins.”  Standard  plug-in  contracts  (1)  for 
service  providers  are  increasingly  common  in  commercial 

framework. 

Framework  Extension  (Plug-In) 

I 

A  component-based  system  is  an  assembly  of  components. 
The  ability  to  predict  the  properties  of  assemblies  suggests 
a  similar  ability  for  subassemblies.  Contract  (1)  is  used  to 
compose  Cl  and  subassembly  C3,  which  contains  one  or 
more  components.  A  question  that  arises  is  whether  C2  is 
visible  outside  of  C3  and  whether  it  is  separately  deployed. 
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The  definitions  in  the  above  table  beg  the  question,  “Which  of  these  forms  of  composition 
(and  therefore  which  class  of  contracts)  are,  or  should  be,  part  of  a  component  model?”  The 
following  comparison  of  component  models  is  revealing.  The  comparison  is  not  intended  to 
be  complete  or  exhaustive,  but  rather  to  reveal  different  perspectives  on  what  should  and 
should  not  be  included  in  component  models. 

A  S  indicates  that  the  component  technology  includes  this  compositional  form  as  part  of  the 
component  model. 


Table  2:  Compositional  Forms  in  Illustrative  Component  Models 
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What  can  be  deduced  from  this?  First,  each  component  technology  defines  deployment  con¬ 
tracts.  This  is  not  surprising,  since  a  component  technology  is  not  of  much  use  unless  com¬ 
ponents  can  be  deployed  into  the  build-time  and  run-time  environments.  Contracts  for  the 
other  compositional  forms  are  not  uniformly  included  in  component  technologies.  Note  that 
none  of  the  illustrated  technologies  addresses  sub-assemblies  in  any  way.  Research  papers 
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have  been  written  on  how  to  support  assemblies  of  COM  components,  but  these  ideas  have 
not  found  their  way  into  commercial  products  [Peltz  99]. 

More  surprising  (at  least  at  first  blush)  is  the  relative  lack  of  attention  to  contracts  for  simple 
composition.  Is  it  true  that  major  technologies  such  as  EJB  and  COM+  ignore  application- 
level  contracts  even  though  component  technology  means  nothing  if  applications  can  not  be 
assembled  from  components?  In  truth,  there  is  a  gray  area  here.  EJB  and  COM+  clearly  say 
something  about  application-level  contracts;  for  example,  how  transactions  are  initiated  and 
propagated.  But  both  EJB  and  COM+  are  relatively  silent  about  what  the  interfaces  to  com¬ 
ponents  look  like.  To  understand  this  statement  it  is  useful  to  compare  EJB  with  JavaBeans 
and  WaterBeans,  each  of  which  requires  component  interfaces  to  conform  to  a  particular 
syntactic  convention,  input  and  output  events  in  the  case  of  JavaBeans,  input  and  output  pipes 
for  WaterBeans. 

Because  JavaBean  and  WaterBean  components  adhere  to  these  conventions,  components  can 
be  written  with  a  high  degree  of  independence  from  each  other,  and  the  assembly  of  applica¬ 
tions  from  components  can  be  left  to  an  assembly  environment  such  as  the  JavaBeans 
“BeanBox.”  Lacking  these  conventions,  however,  EJB  component  developers  must  make 
some  assumptions  about  how  other  EJB  components  will  present  their  services,  and  these 
assumptions  must  be  embedded  in  the  implementation  of  EJB  components.  The  same,  of 
course,  is  true  of  COM+.  The  result  is  a  higher  degree  of  coupling  between  components  and 
reduced  prospects  for  a  market  in  commodity  components.  Instead,  EJB  and  COM+  will  rely 
upon  companies  such  as  the  Theory  Center  to  develop  product  lines  of  components,  or,  per¬ 
haps,  for  industry  groups  to  develop  application-level  contracts  for  particular  market  niches. 

8.2  Binding  Time  of  Composition 

The  above  discussion  touched  on  what  is  composed.  A  discussion  of  how  composition  occurs 
involves  the  question  of  resource  binding.  Essentially,  two  components  are  composed  when 
the  resources  provided  by  one  component  become  accessible  to  a  client  component,  or  are 
bound  to  the  client.  Naming  services  are  one  mechanism  for  resource  binding.  However,  to 
be  complete,  even  after  a  naming  lookup,  many  other  mechanisms  are  involved  in  binding  the 
client  to  the  service  provider  (dynamic  libraries,  remote  procedure  calls,  etc.). 

Although  the  many  mechanisms  involved  in  resource  binding  can  present  a  confusing  picture 
of  the  binding  process,  one  useful  way  to  simplify  things  is  to  consider  the  question  of  when 
resource  binding  occurs.  We  can  think  of  binding  time  as  a  timeline,  with  early  binding  at 
one  end  and  late  binding  at  the  other.  Looking  at  the  development  process  from  the  perspec¬ 
tive  of  software  components,  early  binding  requires  that  the  component  developer  make  some 
decisions  which  effectively  bind  some  resource  to  the  component,  or,  more  to  the  point,  con¬ 
strain  how  this  binding  will  occur  later.  Late  binding  means  just  the  opposite:  the  component 
developer  will  make  no  decisions  that  constrain  future  resource  binding. 
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Two  concrete  examples  will  illustrate  this  distinction.  In  the  case  of  EJB  components,  re¬ 
source  binding  for  application-level  (i.e.,  simple-composition)  assembly  requires  early  bind¬ 
ing  because  the  component  developer  must  make  explicit  reference  to  the  interface  of  the 
type  of  component  that  will  be  provide  some  service.  Although  the  actual  resource  binding 
may  happen  at  runtime,  perhaps  as  a  result  of  a  naming  service  lookup,  this  binding  is  con¬ 
strained  to  only  those  components  that  implement  a  particular  interface.  Moreover,  the  EJB 
component  model  does  not  specify  this  interface,  so  it  is  likely  to  be  non-standard.  In  the 
case  of  WaterBeans  components,  resource  binding  for  application-level  assembly  requires  no 
early  binding  decisions  on  the  part  of  component  developers,  since  all  components  must  write 
obtain  their  input  and  deliver  their  output  to  typed  pipes — this  is  required  by  the  WaterBeans 
component  model. 

However,  the  component  model  must  be  designed  to  encourage  late  binding.  Component 
technologies  such  as  WaterBeans  and  JavaBeans  support  late  binding  by  imposing  additional 
constraints  on  component  developers  on  how  components  expose  their  services,  and  on  how 
components  may  interact  once  their  services  are  bound  to  each  other.  Thus,  the  price  for  late 
binding  is  additional  complexity  in  the  component  model,  and  added  constraints  on  the  way 
components  are  developed  and  on  how  they  expose  their  services  to  potential  clients.  In  ex¬ 
change,  component  models  that  allow  late  binding  offer  greater  flexibility  for  component 
substitution,  for  third-party  integration,  and  for  component  markets. 

Interestingly,  the  design  constraints  needed  to  support  late  binding  of  component  resources 
represent  a  kind  of  early  binding  of  design  decisions,  in  particular  those  that  deal  with  how 
components  coordinate  their  activities  with  each  other.  This  early  binding  of  design  deci¬ 
sions  is  consistent  with  the  overall  “architecture  first”  philosophy  of  CBSE,  and  leads  to  sys¬ 
tems  with  properties  that  are  more  readily  analyzed  and  predicted  prior  to  system  assembly. 

Summary  of  Key  Points 

Composition  enables  interaction  among  the  composed  entities.  In  component-based  systems 
the  primary  entities  of  concern  are  components  and  frameworks.  There  are  six  significant 
forms  of  interaction  (and  hence  composition)  between  components  and  frameworks  that  arise 
in  component-based  systems.  A  component  model  will  define  contracts  that  govern  these  six 
forms  of  interaction.  However,  looking  at  representative  software  component  technologies 
makes  clear  that  although  all  define  deployment  contracts,  there  is  no  consensus  what  other 
kinds  of  composition  should  be  supported,  and  none  of  the  technologies  examined  dealt  with 
component  subassemblies. 
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The  different  treatments  of  application-level  contracts  are  likewise  revealing.  The  major 
commercial  component  technologies,  EJB  and  COM+,  deal  with  some  aspects  of  application- 
level  composition,  but  leave  most  of  these  details  to  be  decided  by  the  component  market. 
This  is  an  understandable  position  to  take,  given  that  each  vendor  wants  to  appeal  to  as  broad 
a  market  as  possible.  Component  technologies  such  as  JavaBeans  and  WaterBeans  take  a 
different  course,  and  constrain  both  the  syntactic  forms  of  a  component’s  application-level 
interface  and  the  coordination  model  underlying  component-component  interactions. 

These  different  treatments  of  application-level  interfaces  are  closely  related  to  the  question  of 
binding  time  of  composition.  The  more  constraining  application-level  contracts  of  Water- 
Beans  and  JavaBeans  allows  late  binding  of  components  to  each  other,  while  the  less  con¬ 
straining  application-level  contracts  of  EJB  and  COM+  require  component  developers  to  bind 
their  components  to  specific,  possibly  non-standard  interfaces,  at  component  development 
time.  In  general,  late  binding  for  application-level  composition  is  preferred  to  early  binding, 
because  it  better  supports  component  substitution  and  the  development  of  component  mar¬ 
kets.  Late  binding  of  application-level  composition  also  leads  to  better  prospects  for  pre¬ 
dicting  overall  system  qualities  prior  to  composition,  precisely  because  late  component 
binding  requires  early  binding  of  architectural  decisions  in  a  component  model. 
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9  Certification 


The  opaqueness  of  implementation  details  means  that  system  assemblers  may  find  it  difficult 
to  diagnose  the  causes  of  unexpected  system  behavior,  and  having  diagnosed  the  cause  affect 
repairs.  This  is  certainly  true  where  conventional  commercial  off-the-shelf  (COTS)  products 
are  used  (see  Plakosh  and  Hissam  for  illustrations),  and  use  of  software  component  technol¬ 
ogy  does  not  fundamentally  alter  this  situation  [Plakosh  99b,  Hissam  99].  Given  the  difficulty 
and  expense  of  diagnosing  these  kinds  of  failures,  the  long-term  success  of  software  compo¬ 
nent  technology  will  hinge  upon  the  availability  of  high-quality  software  components,  and 
trust  on  the  part  of  consumers  that  the  components  that  they  purchase  are  of  high  quality. 

This  leads  to  the  topic  of  certification  of  components. 

Software  certification  is  not  a  new  idea.  In  fact,  certification  has  a  long  history  in  the  soft¬ 
ware  industry.  In  the  most  frequently  encountered  use  of  certification,  some  authoritative 
organization  attests  to  the  fact  that  some  software  system  satisfies  some  criteria,  or  conforms 
to  some  specification.  For  example,  the  National  Security  Agency  (NSA)  might  certify  that  a 
particular  operating  system  complies  with  level  B2  of  the  Trusted  Computer  Security 
Evaluation  Criteria  (TCSEC)  a.k.a.,  Orange  Book  Criteria. 

This  illustration  reveals  two  separate  and  distinct  facets  of  certification: 

1)  Technical  claims  are  made  about  the  subject  of  the  certification. 

2)  An  authority  stands  behind  these  claims  to  generate  trust  in  these  assertions. 

These  different  facets  are  important  insofar  as  they  reveal  the  dual  purpose  of  certification. 
The  first  is  to  establish  facts  about  the  subject  being  certified,  and  the  second  is  to  establish 
trust  in  the  validity  of  these  facts.  While  engineers  may  make  use  of  established  facts  about  a 
system,  trust  has  other  purposes.  While  both  of  these  facets  apply  equally  to  certification  in 
the  context  of  component-based  systems,  the  approaches  that  are  needed  to  make  assertions 
and  build  trust  may  be  different  than  is  otherwise  the  case. 

9.1  Certification  in  Component-Based  Systems 

The  NSA  example  might  be  termed  the  traditional  approach  to  certification.  In  the  tradi¬ 
tional  approach,  the  subject  of  the  certification  is  a  system.  An  authority  attests  to  the  fact 
(certifies)  that  the  system  satisfies  some  objective  target  criteria. 
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But  matters  are  not  so  straightforward  in  a  component-based  approach.  For  one  thing,  the 
subject  of  certification  includes,  in  addition  to  the  end  system,  the  components  and  frame¬ 
works  that  make  up  the  end  system. 


r 


(a)  framework 
certification 


(b)  component 
certification 


(c)  system 
certification 


Figure  4:  Subjects  for  Certification  in  Component-Based  Systems 


This  differentiation  of  certification  subjects  is  already  having  in  impact  on  industrial  soft¬ 
ware,  in  particular  for  certification  of  components  (if  we  momentarily  equate  component  with 
commercial  software  product).  For  example,  in  response  to  the  pressures  of  the  COTS  soft¬ 
ware  marketplace,  NS  A  and  NIST  have  joined  to  create  the  National  Information  Assurance 
Partnership  (NLAP) 10  to  augment,  if  not  wholly  replace,  the  traditional  NSA  security  certifi¬ 
cation  regime.  One  of  the  noteworthy  approaches  of  NLAP  is  the  idea  of  a  protection  profile, 
which  is  essentially  a  slice  through  the  TCSEC.11  One  use  of  protection  profiles  is  to  de¬ 
scribe  certification  criteria  for  particular  classes  of  COTS  products.  For  example,  NIAP  has 
developed  and  approved  a  protection  profile  for  COTS  firewalls.  At  least  eleven  vendors  are 
using  NIAP  certification  against  these  criteria  for  competitive  advantage.12 

But  while  NIAP  has  begun  to  address  the  question  of  certifying  the  security  properties  of 
COTS  components,  it  is  instructive  to  note  the  limitations  of  the  NIAP  approach: 

•  Protection  profiles  are  produced  as  a  response  to  the  emergence  of  classes  of  commercial 
products.  Therefore,  the  scope  of  protection  profiles  will  be  only  as  stable  as  the  prod¬ 
ucts  from  which  they  emanate.  Also,  since  product  vendors  will  continue  to  introduce 
non-standard  and  differentiating  features,  the  profile  is  also  bound  to  provide  only  partial 
coverage  of  the  security  properties  of  products,  and  the  mapping  from  product  features  to 
profile  criteria  will  often  be  highly  subjective. 

•  NIAC  has  partitioned  the  TCSEC  into  product-specific  profiles,  but  has  not  produced  the 
means  of  aggregating  the  different  profiles  exhibited  by  different  products  into  a  coherent 
system-level  model  of  security.  How  should  products  be  combined  that  have  overlapping 
profiles?  Which  criteria  of  one  profile  are  dependent  on  criteria  of  other  profiles?  Most 


10  See  http://niap.nist.gov/howabout.html  for  NIAP  homepage. 

11  Actually,  it  is  a  slice  through  NIAP  common  criteria,  which  are  derived  from  but  reformulate  and 

generalize  the  TCSEC. 

12  See  http://www.lucent.com/press/0199/990120.coa.html  for  a  vendor  press  release,  and 

http://www.niap.nist.gov/cc-scheme/ValidatedProducts.html  for  a  list  of  certified  products. 
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importantly,  how  are  system  security  properties  predicated  on  the  properties  of  the  indi¬ 
vidual  components? 

These  failings  of  NIAP  are  not  the  result  of  naivete  on  the  part  of  NIAP,  but  rather  stem  from 
the  fact  that  NIAP  is  a  reaction  to,  and  is  bound  up  with,  the  dynamics  of  the  COTS  software 
marketplace.  This  marketplace  differs  from  the  software  component  marketplace  in  one  im¬ 
portant  respect:  the  COTS  marketplace  is  products  first,  architecture  second ;  the  component 
marketplace  it  is  application  architecture  first,  components  second.  That  is,  unlike  COTS 
software,  software  components  must  comply  with  a  component  model  that  expresses  numer¬ 
ous  architectural  decisions.  This  difference  provides  a  foundation  upon  which  a  component- 
based  certification  regime  can  be  established. 

To  understand  this  assertion  it  is  useful  to  re-examine  our  motivation  for  certifying  compo¬ 
nents  and  frameworks.  We  then  relate  this  motivation  to  software  architecture  and  to  the 
benefits  of  the  “architecture  first”  approach  inherent  in  CBSE.  Only  then  do  we  turn  to  a  dis¬ 
cussion  of  the  technical  issues  involved  in  certification. 

9.2  Certification,  Prediction,  and  Compositional 
Reasoning 

The  unspoken  premise  behind  component13  certification  is  that  there  is  a  causal  link  between 
those  properties  of  a  component  that  are  certified  and  the  properties  of  an  end  system  that 
uses  that  component.  The  more  confidence  we  have  in  this  link  the  more  value  will  accrue 
from  component  certification.  At  the  extreme  we  may  achieve  100%  confidence  (or  trust)  in 
the  causal  link.  At  this  extreme,  once  a  property  has  been  established  for  a  component  it  is 
unnecessary  to  certify  that  the  end  system  has  obtained  this  same  property,  since  we  know 
this  to  be  true  by  definition. 


It  is  unlikely  that  100%  confidence  will  be  achieved  for  till  (if  any)  of  the  different  kinds  of 
properties  of  interest.  In  the  absence  of  100%  confidence  we  move  from  the  realm  of  cer¬ 


tainty  to  the  realm  of  probability  and  prediction.  In  this  realm  the  value 


of  component  certification  is  proportional  to  the  strength  of 
the  predictions  that  can  be  made  about  end-system 
properties.  Consider  the  graphic  at  right.  System  S 
comprises  two  components.  Cl  and  C2.  Cl  possesses 
property  pi  and  p2,  while  C2  has  property  p3.  Our  interest 
is  in  ensuring  that  system  S  exhibits  property  p4.  In  the 
illustration  we  assert  that  pi  and  p3  are  causally  linked  to  p4. 


For  the  above  diagram,  assume  that  property  p4  is  end-to-end  latency.  If  property  pi  and  p3 
refer  to  the  quality  of  documentation  of  components  Cl  and  C2,  then  the  link  between  pi,  p3 
and  p4  is  non-existent  and  certification  of  documentation  quality  would  be  of  no  value.  Al- 

13  The  following  discussion  applies  equally  to  components  and  frameworks.  We  refer  only  to 
components  to  avoid  excessively  awkward  phraseology. 
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tematively,  if  property  pi  and  p3  refer  to  some  performance  attributes  of  Cl  and  C2  that 
contribute  to  end-to-end  latency,  then  the  value  of  certifying  these  performance  properties 
increases  somewhat.  How  much  this  value  increases  depends  upon  the  strength  of  the  theory 
we  will  use  to  predict  p4  from  the  values  of  pi  and  p3.  If  we  have  a  theory  that  can  predict 
the  latency  p4  from  latency  pi  and  p3  with  only  a  small  margin  of  error,  then  our  knowledge 
of  pi  and  p3  is  useful.  Conversely,  if  our  theory  is  weak  then  our  knowledge  of  pi  and  p3  is 
much  less  useful. 

Such  theories  of  prediction  support  what  we  refer  to  as  compositional  reasoning.  The  adjec¬ 
tive  compositional  reflects  the  belief  (as  software  architects  have  long  asserted)  that  end- 
system  properties  are  most  often  attributable  to  a  collection  of  interacting  components  rather 
than  to  a  single  component.  Thus,  the  properties  of  these  several  parts  must  be  combined 
(“composed”)  to  predict  the  properties  of  the  whole.  There  are  well-established  prediction 
theories,  for  example  Rate  Monotonic  Analysis  (RMA),  that  support  compositional  reasoning 
about  performance  attributes  of  systems. 

Note  that  the  value  of  these  theories  goes  beyond  predicting  system  properties.  Such  theories 
also  tell  us  which  properties  can  be  predicted  (p4),  and,  just  as  important,  which  component 
properties  we  need  to  know  about  in  order  to  make  these  predictions  (pi  and  p3).  The  value 
of  a  certification  regime  for  component-based  systems  is  directly  linked  to  the  strength  of  our 
compositional  reasoning.  Without  compositional  reasoning  we  can  not  know  which  proper¬ 
ties  of  components  and  frameworks  to  certify.  With  weak  compositional  reasoning  the  value 
of  certification  will  be  questionable  and  therefore  the  economic  incentives  for  third-party 
certification  will  never  be  sufficient  to  spur  industry  investment. 

9.3  Compositional  Reasoning  and  Software 
Architecture 

The  connection  between  compositional  reasoning  and  software  architecture  was  just  alluded 
to — the  motivation  underlying  the  study  of  software  architecture  is  prediction  of  system 
properties  from  the  types  of  components  in  a  system  and  their  patterns  of  interaction.  One 
promising  research  avenue,  attribute-based  architecture  styles  (ABAS),  seeks  to  make  com¬ 
positional  reasoning  based  on  architectural  decisions  more  formal,  or  at  least  more  structured 
[Klein  99].  In  brief,  using  ABAS  terminology,  an  ABAS  is  an  architectural  style  and  an  asso¬ 
ciated  attribute-reasoning  framework.  An  ABAS  has  four  major  parts: 

•  a  description  of  the  analysis  problem  solved  by  the  ABAS 

•  a  characterization  of  the  stimuli  to  which  the  ABAS  responds  and  the  quality  attribute 
measures  of  the  response 

•  a  description  of  the  architectural  style  in  terms  of  its  components,  connectors,  topologies, 
and  their  properties.  This  will  be  used  to  structure  the  analysis. 

•  a  reasoning  framework  that  links  stimuli  and  architectural  properties  to  response.  The 
rigor  of  these  frameworks  range  from  heuristics  to  mathematical  formulae. 
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The  fourth  bullet  contains  the  theory  and  compositional  reasoning  that  relates  properties  of 
components  and  frameworks  (the  second  and  third  bullets)  to  end-system  properties  (the  re¬ 
sponse  in  the  second  bullet). 

There  is  a  useful  connection  between  ABAS  and  software  component  technology  in  that  a 
component  model  expresses  architectural  decisions  that  are  imposed  on  component  (and 
framework)  developers.  If  these  component  models  are  equipped  with  an  ABAS-style  rea¬ 
soning  framework,  then  two  things  become  possible.  First,  application  builders  can  use  the 
reasoning  framework(s)  bundled  with  the  component  model  to  predict  end-system  properties 
(one  facet  of  the  SEI  vision  for  CBSE).  Second,  the  reasoning  framework(s)  identifies  those 
properties  that  must  be  known  about  components  and  frameworks,  and  hence  certified. 

More  will  be  said  about  the  connection  of  ABAS  to  a  certification  regime  in  Volume  III  of 
this  report. 

9.4  Certifying  Components  and  Component 
Frameworks 

Certification  depends  upon  compositional  reasoning.  The  theories  underlying  compositional 
reasoning  identify  those  properties  of  components  and  frameworks  that  are  material  for  pre¬ 
dicting  some  end-system  properties  (performance,  safety,  scalability,  etc.).  These  properties 
will  be  contractually  specified  in  a  component  model.  Thus,  certification  of  components  and 
frameworks  reduces  to  establishing  that  they  conform  to  these  contractual  specifications. 
Nonetheless,  at  least  three  significant  technical  challenges  must  be  addressed  before  this  “re¬ 
duction”  can  become  a  routine  practice. 

First,  contractual  specifications  must  be  expressive  enough  to  capture  all  of  the  properties 
imposed  by  frameworks  that  will  lead  to  end  system  quality  attributes,  and  measurement 
techniques  must  be  in  place  to  determine,  to  a  desired  level  of  confidence,  the  degree  to 
which  a  component  exhibits  these  properties.  Interface  specification  techniques  must  be 
adopted  that  strike  a  practical  balance  between  formality  and  usability.  More  formal  specifi¬ 
cations  are  more  expressive  but  introduce  severe  transition  challenges.  Measurement  requires 
that  each  property  expressed  in  an  interface  be  defined  precisely  according  to  some  meas¬ 
urement  scale.  In  addition,  sufficient  laboratory  testing  techniques  must  be  defined  to  pro¬ 
duce  accurate  measurements  on  software  components — ideally  where  these  components  re¬ 
main  “black  boxes.” 

Second,  having  specified  and  measured  all  of  the  relevant  properties,  it  is  still  necessary  to 
define  the  conformance  relation  between  a  component  and  a  contractual  specification  of  a 
role  it  must  fill.  Some  aspects  of  conformance  are  straightforward:  a  component  property 
that  over-satisfies  a  minimum  threshold  on  a  criterion  should,  we  expect,  be  conformant.  But 
what  if  the  desired  property  is  associated  with  an  interaction  among  three  components,  for 
example,  and  the  entire  interaction  must  occur  within  60ms  for  the  property  to  be  satisfied? 
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Is  it  proper  to  assume  that  each  component  must  execute  within  20ms,  or  might  one  execute 
in  10ms  while  each  of  the  others  execute  in  25ms?  In  this  case  it  might  be  best  to  certify  the 
performance  value  of  a  component  without  imposing  a  minimum  threshold.  But  without  a 
minimum  threshold  how  can  conformance  be  defined?  This  suggests  that  components  and 
frameworks  have  properties  whose  values  are  certified,  but  that  the  question  of  conformance 
needs  to  be  deferred  until  later  in  the  development  process,  possibly  as  late  as  runtime. 

Third,  component  models  are  not  monolithic,  and  a  component  technology  may  specify  some 
aspects  of  a  component  model  but  leave  other  aspects  to  be  specified  by  industry  groups  or 
application  developers.  Thus,  as  we  saw  earlier,  the  EJB  component  model  is  nearly  silent 
about  application-level  contracts  ( simple  composition  in  Table  1).  WaterBeans  is  explicit 
about  application-level  contracts,  specifying  the  form  that  these  interfaces  take,  how  they  can 
be  connected,  and  how  control  and  data  flow  through  these  connections.  By  virtue  of  this 
greater  detail,  certifying  components  for  WaterBeans  will  be  more  effective  for  predicting 
application-level  properties  than  would  be  the  case  for  EJB  components.  The  point  is  that  the 
component  certification  regime  will  be  only  as  effective  as  component  models  allow. 
Moreover,  component  models  must  be  designed  with  component  certification  in  mind. 

9.5  Process  Certification 

The  entire  discussion  so  far  has  focused  on  the  direct  technique  of  certifying  software  prod¬ 
ucts.  An  alternative  (or  at  least  complementary)  and  indirect  approach  is  to  certify  the  proc¬ 
esses  used  to  produce  the  artifacts.  Whether  certifying  a  process  will  yield  the  level  of  trust 
that  certifying  a  product  will  depends  upon  how  strongly  a  causal  link  can  be  established 
between  process  quality  and  product  quality.  Should  the  link  be  strong,  process  certification 
may  prove  to  be  an  economical  alternative  to  product  certification. 

Note  that  process  certification  is  not  entirely  conjectural.  Underwriters  Laboratory  has  pub¬ 
lished  its  standard  for  certifying  software  in  programmable  components'4  [UL  98].  While 
this  standard  addresses  product  certification  in  the  traditional  sense  (inspections,  testing, 
etc.),  it  also  includes  certification  of  the  development  process.  For  example,  the  development 
process  is  examined  to  determine  that  every  process  step  has  well-defined  entry  and  exit  cri¬ 
teria.  The  tools  used  by  the  development  environment  are  also  “qualified,”  meaning  that  they 
must  have  a  documented  “bug”  list  among  other  things. 

Consider  hypothetical  components  or  frameworks  being  certified  as  “100%  Cleanroom  De¬ 
veloped.”  If  it  is  established  in  the  public  eye  that  cleanroom  development  consistently  pro¬ 
duces  “zero  defect  software,”  then  such  a  certification  regime  might  be  effective.  Similarly, 
although  this  is  a  bit  of  a  stretch,  the  process  of  assembling  applications  from  certified  soft- 


14  The  term  programmable  component  is  defined  by  Underwriters  Laboratory  as  “Any  microelectronic 
hardware  that  can  be  programmed  in  the  design  center,  the  factory,  or  in  the  field.  Here  the  term 
‘programmable’  is  taken  to  be  ‘any  manner  in  which  one  can  alter  the  software  wherein  the 
behavior  of  the  component  can  be  altered.’  ” 
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ware  components  might  also  be  certified.  This  might  be  feasible  should  compositional  rea¬ 
soning  about  key  properties  (security,  for  example)  be  sufficiently  trustworthy. 

Summary  of  Key  Points 

Certification  involves  two  separate  actions:  1)  establishing  that  a  (software)  subject  possesses 
particular  properties,  most  often  in  conformance  with  some  specification  against  which  a 
component  or  framework  is  certified;  and  2)  having  a  trusted  agent  or  organization  attest  to 
the  truth  of  this  conformance.  The  first  of  these  actions  has  consequence  on  the  engineering 
discipline,  in  that  application  developers  can  work  with  “known  quantities.”  The  second  of 
these  actions  has  consequence  on  the  development  of  consumer  trust.  Both  are  necessary. 

The  ultimate  motivation  for  establishing  that  a  component  or  framework  possesses  some 
property  is  to  use  that  knowledge  to  predict  some  property  of  the  assembled  application. 
Theories  and  techniques  that  can  link  component  and  framework  properties  to  application 
properties  are  said  to  support  compositional  reasoning.  Compositional  reasoning  identifies 
which  properties  of  components  and  frameworks  are  material  to  achieving  some  end-system 
property,  and  how  to  predict  the  “values”  of  end-system  properties  from  component  and 
framework  properties.  The  effectiveness  of  a  certification  regime  improves  as  our  ability  to 
undertake  compositional  reasoning  improves. 

The  NIAP  approach  to  certifying  the  security  properties  of  COTS  software  products  is  a  re¬ 
sponse  to  the  industry  trend  towards  the  use  of  software  components.  But  the  COTS  software 
marketplace  provides  a  “product  first,  architecture  second”  context  for  NIAP  certification, 
leading  to  an  unstable  understanding  of  what  properties  must  be  certified  for  particular 
classes  of  products,  and  to  weak  compositional  reasoning  schemes.  In  contrast,  software 
component  technology  provides  an  “architecture  first,  component  second  context  for  certifi¬ 
cation.  This  shift  in  emphasis  provides  the  means  to  overcome  some  of  the  deficiencies  of 
the  NIAP  approach. 


One  such  promising  means  is  attribute-based  architectural  styles  (ABAS).  An  ABAS  couples 
attribute-specific  compositional  reasoning  techniques  with  architectural  styles.  Since  com¬ 
ponent  models  are  specifications  of  architectural  decisions,  one  or  more  ABASs  can  be  asso¬ 
ciated  with  a  particular  component  technology.  This  in  turn  would  identify  those  properties 
of  the  framework  and  of  components  that  must  be  certified,  and  define  how  these  certified 
properties  can  be  used  to  predict  the  properties  of  the  assembled  application. 

Using  ABASs  as  a  foundation  for  a  component-based  certification  regime  requires  three 
technical  issues  be  addressed.  First,  techniques  for  contractual  specification  must  be  ex¬ 
tended  to  include  any  and  all  properties  required  by  an  ABAS,  and  measurement  techniques 
must  be  identified  to  establish  whether  components  exhibit  these  properties.  Second,  con¬ 
formance  must  be  re-defined  to  allow  assemblers  to  decide  whether  a  component  or  frame¬ 
work  “passes  muster.”  In  effect,  we  must  certify  the  values  of  component  or  framework 
properties  without  necessarily  superimposing  normative  guidelines  on  what  these  values  must 
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be.  Third  and  last,  component  models  (and  hence  component  technologies)  must  be  defined 
a  priori  to  support  a  certification  regime.  Failing  this,  components  will  not  be  easily  certi¬ 
fied,  or  the  causal  link  between  component  property  and  system  property  will  be  weak. 
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10  Conclusions 


Component-based  systems  are  the  result  of  structuring  a  system  according  to  a  particular  de¬ 
sign  pattern.  This  design  pattern  relies  upon  a  number  of  closely  related  technical  concepts, 
including:  components,  component  frameworks,  component  models,  component  composition, 
component  interfaces,  contracts,  and  certification. 

There  are  several  motivations  for  the  component-based  approach  to  software.  Components 
and  industry  standard  component  models  provide  a  basis  for  commerce  in  reusable  software, 
something  that  is  required  if  US  industry  is  to  meet  current  and  projected  demand  for  soft¬ 
ware.  Components  are  replacement  units  in  systems,  thus  facilitating  the  development  of 
software  systems  that  are  more  flexible  and  less  likely  to  become  prematurely  obsolete. 
Component  models  express  numerous  design  decisions,  and  component  frameworks  provide 
an  integrated  environment  for  component  execution;  together  these  serve  to  drastically  reduce 
the  time  it  takes  to  design,  implement  and  deploy  systems. 

Despite  these  potential  benefits,  one  critical  aspect  of  component-based  software  has  yet  to 
be  adequately  addressed:  the  need  for  systems  that  will  predictably  exhibit  the  quality  attrib¬ 
utes  required  of  them.  Consumers  of  commercial  component  technologies  must  rely  upon 
off-the-shelf  component  models  and  frameworks  to  provide  the  foundation  for  achieving 
system  quality  attributes.  While  component  technology  vendors  make  claims  about  how  their 
products  yield  these  attributes,  the  technical  basis  for  these  claims  is  questionable.  There  is, 
as  yet,  no  established  basis  for  assessing  how  well  component  models  and  frameworks  con¬ 
tribute  to  achieving  desired  quality  attributes;  nor  is  there  any  current  basis  for  assessing  the 
quality  of  software  components  and  how  they  contribute,  or  hinder,  achieving  these  quality 
attributes. 

In  light  of  this,  the  SEI  has  adopted  a  “vision  statement”  for  component-based  software  engi¬ 
neering  that  focuses  on  the  question  of  predictable  system  assembly  from  certified  compo¬ 
nents  and  frameworks.  This  vision  statement  provided  the  filter  through  which  a  wide  array 
of  technical  concepts  was  examined.  The  technical  concepts  discussed  in  this  report  culmi¬ 
nate  in  a  discussion  of  component  and  framework  certification,  and  how  the  “architecture 
first”  approach  inherent  in  component-based  systems  provides  a  basis  for  certification  and 
predictable  assembly.  A  detailed  description  of  a  technical  agenda  to  build  on  this  basis  is  the 
topic  of  Volume  III  of  this  report. 
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